Closed Bug 19416 Opened 25 years ago Closed 25 years ago

Drop down displays in the wrong place

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rods, Assigned: rods)

References

(
URL
)

Details

(Whiteboard: [PDT-])

Attachments

(1 file)

Reduced test case
524 bytes, text/html
Details
Troy's changes to the frame now has the drop down being placed incorrectly.
Whiteboard: [PDT+]
putting on PDT radar
Attached file Reduced test case —
The issue is the CENTER tag. What happens is that on the way down the frame tree the table is placed at (0, 0), and then after reflowing the table the block sees that it should be center aligned and moved it. That by itself is not significant, and the block re-positions any views that are out of sync. The problem is that the combobox frame positions the pop-up view in its DidReflow() handler, and the DidReflow() handler has already been called (we no longer do DidReflow() as a separate pass over the tree). Hence the view is no longer positioned correctly
Okay, I made a change to PositionFrameView() and SyncFrameViewAfterReflow() so they go ahead and position the view correctly in the case where the parent view is not equal to the containing view. The previous code tried to play it safe and not move the view in that case. This kept us from moving it to the wrong place, but didn't help in cases like this one where the CENTER causes the table to be moved and then the view is out of sync This should be a good enough workaround until you can change it so the view hierarchy matches the frame hierarchy. You still do need to make that change
I am seeing some odd behavior when the drop down is being shown and then you click down on the button to roll it up. It either briefly slides to the left or changes size (I think it briefly slides to the left). I am not sure which end it is on, I will a quick look at it and see if it is easily fixed in the select code, but it is something we can live with until we rework the other code.
The reason you're seeing it move is because of the way the block code implements CENTER. It positions the table as if it were left-aligned, then after reflowing it decides to center it and so it moves the frame thus causing all of the child views to be moved Why are we even doing a reflow when you click on the button to roll the pop-up back up? We need to eliminate all unnecessary reflows, because they are performance problems when tables are involved. I would have thought that you would just change the style to show the pop-up is hidden (or collapsed) and then we wouldn't need a reflow
Another solution, which I would rather not do, is to add an API to the view code so we tell it when we befin moving views and when we end. It would defer moving widgets until we tell it we're done. In this case before reflowing the block we would call it and then after we're finished we would call it and say we're done The problem with this approach is that it's really just covering up the ereal issues. In this case: - all the reflows we're doing that hopefully can be eliminated - the block code needs to be smarter when doing incremental and resize reflows and assume the current position will be correct and not unnecessarily move elements
Rod wants to reduce this from PDT given Troy's fix. They plan to move to new API, so no point in wasting time fixing a moving target.
Can we get a Friday delivery date for the fix? Thanks!
Whiteboard: [PDT+] → [PDT-]
Moving to PDT- per rickg comments and PDT mtg.
changed to M14
*** Bug 20426 has been marked as a duplicate of this bug. ***
Here is a better URL: http://www.ebay.com
Status: NEW → ASSIGNED
One of the problems is that collapse is causing a reflow. A while back peter changed the code to better adhere to the CSS spec and then said the drop-down should be using collapse instead of hidden. He then changed it to collapse. If I change it back to hidden, it is very fast (probably no reflow) and always pops up in the correct place. I will be checking this in when the tree opens. It think bug should be severly downgraded to minor or ehancement, meaning we still need to have the view hierarchy match the frame hierarchy, but this work depends on the compositor being reworked.
Turns out I can't change it to hidden, it works some of the time, but other times, really bad things happen. Back to looking for reflows....
QA Contact update.
*** Bug 20992 has been marked as a duplicate of this bug. ***
*** Bug 21488 has been marked as a duplicate of this bug. ***
moving to M15
Putting dogfood in the keyword field.
Keywords: dogfood
Summary: [DOGFOOD]Drop down displays in the wrong place → Drop down displays in the wrong place
this is fixed by my combo checkin
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking VERIFIED FIXED on: - Linux6 2000-03-17-06 Commercial nb1n build - MacOS9 2000-03-16-16 Commercial nb1n build - Win98 2000-03-16-06 Commercial nb1n build - WinNT 2000-03-16-06 Commercial nb1n build
Oops. Forgot to actually click the 'Mark bug as VERIFED' radio button...
Status: RESOLVED → VERIFIED
There's a pile of code marked "Temporary fix for Bug #19416", revolving around nsView::IgnoreSetPosition. Did that become the "permanent fix", or should this code be removed? The code looks like a grotesquely ugly hack...
Is there a reason that SyncViewWithFrame() is called in DidReflow()? I'm finding it a performance problem under Linux. When loading a page with many drop downs each listbox calls SyncViewWithFrame during creation of the page. This eventually leads to calls to nsWindow::WidgetToScreen which on X calls XTranslateCoordinates which stalls the X communications waiting for a reply. I've tried to move the call to nsListControlFrame::AboutToDropDown() doing lazy view syncing, and this seems to work for the tests I've done.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: