Closed Bug 508115 Opened 11 years ago Closed 11 years ago

some drop down fields misaligned in options panel


(Core :: XUL, defect, P2)




Tracking Status
status1.9.2 --- beta1-fixed


(Reporter: xtc4uall, Assigned: roc)



(Keywords: regression, verified1.9.2)


(3 files)

in Fx options panel several drop down fields are misaligned, e.g.
- content/fonts & colors/advanced: size fields
- privacy/history/custom settings/third party cookies: keep until drop down

also see the screenshots mentioned in

regression range:
Flags: blocking1.9.2?
Clearly a blocker...
Assignee: nobody → roc
Flags: blocking1.9.2? → blocking1.9.2+
This is the new code in bug 506615 that calls CreateViewForFrame for the children of deck frames. When the deck child contains a popup menu, this is causing menupopup frames, which already have views, to have those views reparented from the root view to the deck child's view. This breaks things. I'm not quite sure of the best fix. We could go back to having FrameNeedsView check for a deck parent but I didn't like polluting that code with decks.
We probably should fix things so that view reparenting doesn't mess with menupopup views in general. I bet there's a related bug where reparenting views due to reflow messes up a menupopup child.
Isn't all this temporary anyway?  (Seems easy enough to put back something like the old code?)
Priority: -- → P1
Attached file testcase
This testcase asserts twice, once for the menulist-in-deck situation and once for the menulist-in-wrapping-span-with-transform situation. The popups appear in the wrong places, but I can't find a way to test the popup position; boxObject.screenX/Y lie and give us the right position.

Although this is a little obscure I think we should fix both bugs.
Attached patch fixSplinter Review
This stops us from reparenting a popup's view which needs to always have the root as its parent.
Attachment #392411 - Flags: review?(dbaron)
Attachment #392411 - Flags: review?(dbaron) → review+
Whiteboard: [needs landing]
This is a P1 1.9.2 blocker, thus blocking Firefox 3.6a1 - any ETA on landing? (not sure this really needs to be a P1, though)
It's ready to land, I'll land it today if I can.
Keywords: checkin-needed
Priority: P1 → P2

But I had to disable the test, it was failing:
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/mozilla-central-linux-unittest-everythingelse/build/reftest/tests/layout/generic/crashtests/508115-1.html | timed out waiting for onload to fire
Closed: 11 years ago
Resolution: --- → FIXED
The popups don't show up in the reftest harness. This probably needs to be rewritten as a mochitest.
Flags: in-testsuite?
Attached patch fixed testSplinter Review
This fixes the test, making it a mochitest.
Keywords: checkin-needed
Whiteboard: [needs landing]
Mass change: adding fixed1.9.2 keyword

(This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)
Keywords: fixed1.9.2
Verified fixed on OS X and Windows with builds like with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090903 Namoroka/3.6a2pre (.NET CLR 3.5.30729) ID:20090903051734

Roc, is the test ready to land?
Keywords: verified1.9.2
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Keywords: checkin-needed
Whiteboard: [needs landing]
Test checked in:
Flags: in-testsuite? → in-testsuite+
Keywords: checkin-needed
Whiteboard: [needs landing]
You need to log in before you can comment on or make changes to this bug.