1055702 - <menupopup> for <menulist> appears at the wrong position under some circumstances

Status: RESOLVED DUPLICATE of bug 1130400

(Core :: Layout, defect)

Description

[obrufau]

Attachment: Demo

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140819030202

Steps to reproduce:

Open the attached demo, and open the dropdowns.


Actual results:

The 2nd and 3rd dropdowns are opened at a wrong position.


Expected results:

<menupopup> should appear just below <menulist>

Comment 1

[:Gijs (he/him)]

tn, do you have time to have a look at this? This is broken on 31 and 34 alike, so I don't think bug 467442 regressed this (that's in 33) so I'm not sure what's up yet, but I presume it's the same/similar code that's getting confused about something or other...

Comment 2

[obrufau]

(In reply to :Gijs Kruitbosch from comment #1)
> tn, do you have time to have a look at this? This is broken on 31 and 34
> alike, so I don't think bug 467442 regressed this (that's in 33) so I'm not
> sure what's up yet, but I presume it's the same/similar code that's getting
> confused about something or other...

Oh, I forgot to mention I could reproduce that on old Firefox 3, and even firefox 2, which displays the page differently, has some problems opening the dropdowns.

Comment 3

[Alice0775 White]

on Windows7, I am able to reproduce the problem on 3rd dropdown only.  I get the following regression window.

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7cf9ff845a1e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140702134153
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0f7f4d5f5e45
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140702135755
pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7cf9ff845a1e&tochange=0f7f4d5f5e45

Suspect: 
	290b06120a69	Susanna Bowen — Bug 1033052 - Call SetRect in ReflowFrame since the old rect does not need to be preserved. r=dbaron

Comment 4

[Alice0775 White]

[Tracking Requested - why for this release]: regression sing Firefox33 on least windows7

Comment 5

[Lawrence Mandel [:lmandel] (use needinfo)]

From comment 1 and comment 2 I take it this issue goes back much farther than 33. If that's the case, I'm reluctant to consider a fix this late in Firefox 34 and would prefer to take a fix in Firefox 35.

I'm leaving 34 as a nom for now. I have also nommed ESR, although I'm not aware of any feedback from ESR users suggesting that we need to take a fix there.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Neil, any chance you'd be able to look at this?

Seems to be a regression from a slight (and long-overdue) change in the way we Reflow frames.

Comment 7

[Lawrence Mandel [:lmandel] (use needinfo)]

We're going to build with the final 34 beta tomorrow. I haven't seen progress in this bug and think we can reasonably ship again with this bug. I'm marking 34 as won't fix. I also haven't heard any ESR feedback about this issue so think we shouldn't track for ESR at this point. We can still consider a simple fix for ESR.

Comment 8

[Neil Deakin]

Multiple reflows occur when the popup is opened. The first reflow is correct. The second however reflows the popup with the parent frame at its unwrapped position. That is, aAnchorFrame->GetRect() returns an xy position that is where the the menu button anchor would be if it had not wrapped to the second line.

Some more reflows occur alternating between the two results, with the incorrect result occurring last.

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

This has been in-product for a significant duration so I'm untracking, we can consider a low risk uplift if/when something is nominated.  This would not be considered for ESR without explicit requests from ESR user base.

Comment 10

[Alice0775 White]

Attachment: testpopup.xul

Another example <button type="menu">.

Comment 11

[Timothy Nikkel (:tnikkel)]

Bug 1130400 should likely fix this.

Comment 12

[obrufau]

(In reply to Timothy Nikkel (:tn) from comment #11)
> Bug 1130400 should likely fix this.

True, seems fixed now.

(In reply to Alice0775 White from comment #3)
> on Windows7, I am able to reproduce the problem on 3rd dropdown only.  I get
> the following regression window.
> 
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7cf9ff845a1e&tochange=0f7f4d5f5e45

Weird. Now it's the same for me, on the same system where I could reproduce the bug with much older Firefox versions. Maybe some Windows update changed something?

In that case, maybe now seems fixed, but it isn't for those without the update. Should this be investigated?