Closed
Bug 35740
Opened 25 years ago
Closed 24 years ago
Native widget in scrolling views prevent clipping of text controls
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M17
People
(Reporter: jon, Assigned: kmcclusk)
References
Details
(Whiteboard: [nsbeta2+] [6/15])
Attachments
(5 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details |
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.
Comment 1•25 years ago
|
||
Could you please provide a simple test case, this will help.
Rod
Comment 2•25 years ago
|
||
adding kevin to cc'list
Reporter | ||
Comment 3•25 years ago
|
||
Reporter | ||
Comment 4•25 years ago
|
||
Comment 5•25 years ago
|
||
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.
Assignee: rods → buster
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.
Status: NEW → ASSIGNED
Comment 8•24 years ago
|
||
Reassigning to beppe (editor).
Assignee: buster → beppe
Status: ASSIGNED → NEW
Assignee | ||
Comment 9•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
nsbeta2. This is serious blocker preventing use of Gecko/Mozilla as a platform
for web apps.
Keywords: nsbeta2
Comment 12•24 years ago
|
||
[nsbeta2+] [6/1] Would take fix for 6/1. jon williams: how about putting a
bounty on this bug?
Whiteboard: [nsbeta2+] [6/1]
Comment 13•24 years ago
|
||
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.
Assignee: buster → kmcclusk
Summary: HTML Form controls are handled differently than other elements → Native widget in scrolling views prevent clipping of text controls
Assignee | ||
Comment 14•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Assignee | ||
Comment 15•24 years ago
|
||
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)
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
Assignee | ||
Comment 18•24 years ago
|
||
Assignee | ||
Comment 19•24 years ago
|
||
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.
Whiteboard: [nsbeta2+] [6/1] → [FIX][nsbeta2+] [6/1]
Assignee | ||
Comment 21•24 years ago
|
||
I'm waiting for ender-lite to land before I check in my patch.
Comment 23•24 years ago
|
||
Updating from [6/1] to [6/15]
Whiteboard: [FIX][nsbeta2+] [6/1] → [FIX][nsbeta2+] [6/15]
Assignee | ||
Comment 24•24 years ago
|
||
I have tested the fix with WIN32, Linux, and Mac. Just waiting for the tree to
open today to check in.
Whiteboard: [FIX][nsbeta2+] [6/15] → [FIX][nsbeta2+] [6/15] Fix tested will checkin today
Comment 25•24 years ago
|
||
Fix is in. PDT, please leave nsbeta2+ until we can test this fix.
Assignee | ||
Comment 26•24 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 27•24 years ago
|
||
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;
Whiteboard: [FIX][nsbeta2+] [6/15] Fix tested will checkin today → [FIX][nsbeta2+] [6/15]; need kmcclusk feedback-ckritzer;
Comment 28•24 years ago
|
||
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 29•24 years ago
|
||
Removed [FIX] from status. Don't have a FIX for the WIN98 problem yet.
Whiteboard: [FIX][nsbeta2+] [6/15]; need kmcclusk feedback-ckritzer; → [nsbeta2+] [6/15]; need kmcclusk feedback-ckritzer;
Assignee | ||
Comment 30•24 years ago
|
||
Removed "need kmcclusk feedback-ckritzer;" from status line
Whiteboard: [nsbeta2+] [6/15]; need kmcclusk feedback-ckritzer; → [nsbeta2+] [6/15]
Assignee | ||
Comment 31•24 years ago
|
||
Tested 7/20/2000 build on WIN98 and clipping is working correctly.
Marking WORKSFORME.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•