Closed Bug 2595 Opened 26 years ago Closed 25 years ago

[PP]Widgets positioning gets messsed up: resizing, scrolling

Categories

(Core :: Layout: Form Controls, defect, P2)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sdm, Assigned: ramiro)

References

(
URL
)

Details

(Whiteboard: I have a fix dammit.) 

If you go to the above url (or any other web page with a submit button), and
the submit button is not visible (ie, you need to scroll to see it), mousing
over the submit button causes it to disappear (turns gray).  After forcing an
expose event, the button will display correctly.

If the submit button is half visible (ie resource:/res/samples/test5.html ) when
the page loads, only the part that WAS visible when the page loaded gets the gtk
highlight when you mouse over it - the rest of the button does not change.
Expose events don't have any effect here.

Any submit buttons that you do not need to scroll to see behave nicely.

This was tested using gtk1.1.13.
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
marking all non-functionality m4 bugs of mine to m5 as i won't be around for the
next week or two.
Assignee: pavlov → ramiro
Status: ASSIGNED → NEW
Summary: submit buttons disappear if scrolled to. → Widgets positioning gets messsed up when resizing and scrolling
Target Milestone: M5 → M4
changing summary

reassign to ramiro

marking m4
Status: NEW → ASSIGNED
Target Milestone: M4 → M5
marking m5.
phillip, is this Linux only?  or ALL platforms.
*** Bug 2850 has been marked as a duplicate of this bug. ***
From bug #2850, here's a reduced test case:
http://blueviper/forms/resizejumper.html
in answer to jan's question, yes, this is a linux only bug, as of build
1999-04-28-0[89] on MacOs 8.51, RedHat 5.2, and WinNT 4
Target Milestone: M5 → M6
wont get to this till m6.

marking m6.
Summary: Widgets positioning gets messsed up when resizing and scrolling → [PP]Widgets positioning gets messsed up when resizing and scrolling
Putting on [PP] radar.
*** Bug 6007 has been marked as a duplicate of this bug. ***
*** Bug 5306 has been marked as a duplicate of this bug. ***
*** Bug 2609 has been marked as a duplicate of this bug. ***
Whiteboard: high dup count-
marking m7.  i cant make m6 for this bugs.
*** Bug 6822 has been marked as a duplicate of this bug. ***
Summary: [PP]Widgets positioning gets messsed up when resizing and scrolling → [PP]Widgets positioning gets messsed up: resizing, scrolling
This bug covers scrolling, I'll let bug 6192 cover form submission.
They don't look like dups to me, maybe ramiro knows more.
*** Bug 6192 has been marked as a duplicate of this bug. ***
Whiteboard: high dup count- → high dup count- working on it 6/16
Target Milestone: M7 → M8
-> m8
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.
Ugh, bugzilla was hobbling, it is back to being horribly broken again.
I push on the [query] button and the widgets move around, no submission occurs.
ramiro wrote:
this widget positioning bug is complicated.  The problem is that the view
manager is computing offsets based on the bounds (x,y) of the widgets.
And for gtk these are always 0,0.
When gfx widgets land, this bug will be fixed.
its not worth it to hack the xp view manager code just for m8.
Target Milestone: M8 → M9
*** Bug 4277 has been marked as a duplicate of this bug. ***
*** Bug 9873 has been marked as a duplicate of this bug. ***
*** Bug 10073 has been marked as a duplicate of this bug. ***
*** Bug 7376 has been marked as a duplicate of this bug. ***
*** Bug 6080 has been marked as a duplicate of this bug. ***
Target Milestone: M9 → M10
-> m10
Target Milestone: M10 → M9
marking m9.

I have a good fix for this bug.   alecf@netscape.com and akkana@netscape.com are
testing it.
Whiteboard: high dup count- working on it 6/16 → I have a fix dammit.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I just checked in a fix for this. YAY!

Marking fixed.

To test, go to any web page that has text fields and resize the window.  The
text widgets should be properly placed as they were before the window resize.
*** Bug 10581 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
verified fixed on

     1999-09-13-08-M10 RedHat Linux 6.0 (GNOME/enlightenment)
You need to log in before you can comment on or make changes to this bug.