I have been attempting to design Web-based apps with NS for some time now, and a MAJOR show-stopper has been that there is no way to clip HTML form elements. My organization is willing to spend developer time and money to see this problem addressed before the final release of NS 6.0 We need to be able to position elements over form elements as well as clipping form elements. The current layout model does not take clipping or z-order into account, thus all form elements bleed through to the top. That keeps us from doing div-based windows in our apps, and that means we can't write cross-browser compatible code. If you have questions or concerns, feel free to contact me: jon@trifolium.com or jon@shovemedia.com Again, we're willing to devote our own resources to see that this is fixed. If this report needs to be sent elsewhere, let me know.

Could you please provide a simple test case, this will help. Rod

adding kevin to cc'list

Reassign this to buster at his request. The issue here is that textareas and input text (when they have focus) have instaniated the editor which at the moment requires a native window. We are currently working removing the dependency on on native windows. travis@netscape.com is currently working on this, about 75% of the work has been done.

Confirming. Gerv

cc-ing Travis. Travis and Kevin, is there some portion of the work you could use help with to accelerate progress on native widget removal? jon@shovemedia.com has time and motivation to spend on this problem. I'd love to see his team integrated into the project. Are there any other roadblocks to enabling docshells to play nice in z-order? jon@shovemedia.com: sorry for the slow response, I've been on vacation the past few days.

Reassigning to beppe (editor).

To completely remove the widget's used by the text field and text area elements we need to be able to optionally create widgets in the ContentViewer. Currently, ContentViewer always creates a widget.

back to buster

nsbeta2. This is serious blocker preventing use of Gecko/Mozilla as a platform for web apps.

[nsbeta2+] [6/1] Would take fix for 6/1. jon williams: how about putting a bounty on this bug?

changed the summary. This won't make beta2 without considerable effort. Removed nsbeta2+ designation to trigger a re-evaluation. The two dependancies for this bug are turning on Ender Lite (to get rid of the webshell in heavyweight text controls), and removing native widgets from scrolling views (Kevin, correct me if I'm wrong about this second part.) I think that when that work is done, this problem will just go away and clipping will work automatically. Do you need this badly enough for Kevin to drop everything and try to squeeze in native widget removal from scrolling views? The task here is probably too big and risky for beta2. Since Ender Lite is covered elsewhere (mjudge, can you add the dep?), I'm assigning this to kevin for the native widget removal work.

I'm working on this now. Once we switch to the ender-lite widget, There are two problems, removing the widget used by the ScrollPort view and getting the compositior to honor clipping of ScrollPort views.

I am very close to having a solution which will work for text fields and text areas. We will be able to clip them and layer them. My solution will not apply to scrolling div's however. ETA (6/3)

To fix clipping and layering of textfields and textarea's install the viewpatch and scrollpatch and build mozilla/layout with MOZ_ENDER_LITE=1 The simple test case uses overflow:hidden instead of clip: rect(...). We do not support clip: rect yet. This should be filed as a separate bug.

Setting Milestone to M17

I'm waiting for ender-lite to land before I check in my patch.

Adding dependency on bug 34896

Updating from [6/1] to [6/15]

I have tested the fix with WIN32, Linux, and Mac. Just waiting for the tree to open today to check in.

Fix is in. PDT, please leave nsbeta2+ until we can test this fix.

Removed the clip widget used by ender-lite widgets. This change involved a change in the nsViewManager and nsScrollPortFrame.cpp. I modified nsScrollPortFrame to check to see if it was inside a nsGfxTextControlFrame to determine whether it should create the clip widget for the scroll frame. I modified nsViewManager::UpdateView to restrict the area that is invalidated to be the clipped region of the view. This was necessary because the content area within the ender lite widget extended beyond the width of it's view when more characters where entered than what could be displayed within the text field or textarea without scrolling. Previously UpdateView would invalidate what ever rect you gave it. This caused a problem when the ender-lites clip widget was removed because calling UpdateView with the large rect caused an area larger than the view to be invalidated, but when it came time to paint only the clipped portion of the view was rendered. This caused garbage to be displayed to the right of the ender-lite widget.

Kevin, could you describe what attach_id=9470 is supposed to be doing? There's a bunch of stuff clumped together, but no description of how it should look, screenshot, etc. The testcase attach_id=7650 appears to work fine... Changed status whiteboard from: [FIX][nsbeta2+] [6/15] Fix tested will checkin today to: [FIX][nsbeta2+] [6/15]; need kmcclusk feedback-ckritzer;

Re-opening. Looks fine on: - MacOS9 2000-07-18-10-M17 Commercial - Linux6 2000-07-19-10-M17 Commercial But clipping is not correct on: - Win98 2000-07-19-11-M17 Commercial

Removed [FIX] from status. Don't have a FIX for the WIN98 problem yet.

Removed "need kmcclusk feedback-ckritzer;" from status line

Tested 7/20/2000 build on WIN98 and clipping is working correctly. Marking WORKSFORME.

Using 7_20_08 build on Win 98, verified fixed.