Last Comment Bug 592954 - Can not select sub-menuitem in pull down menu at the top of page
: Can not select sub-menuitem in pull down menu at the top of page
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: x86 All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://mozilla.jp/
Depends on: 601547
Blocks: 130078
  Show dependency treegraph
 
Reported: 2010-09-01 23:12 PDT by Alice0775 White
Modified: 2010-10-11 13:57 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+


Attachments
semi-reduced testcase (3.36 KB, text/html)
2010-09-15 12:36 PDT, Timothy Nikkel (:tnikkel)
no flags Details
patch (6.08 KB, patch)
2010-09-26 18:35 PDT, Timothy Nikkel (:tnikkel)
bugs: review-
Details | Diff | Review

Description Alice0775 White 2010-09-01 23:12:51 PDT
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre ID:20100901210607

I can not select sub-menuitem in pull down menu at the top of page.
The pull down menu is closed immediately when I move mouse pointor into the pull down menu.

It can be select on Firefox 3.6.8.

Reproducible: Always

Steps to Reproduce:
1.Open Minefield
2.Open ( http:www.mozilla.japan )
3.Move mouse over dark blue menu at the top of page
4.Try to select sub-menuitem in the pull down menu.

Actual Results:  
I can not select menuitem
Comment 1 Kohei Yoshino [:kohei] 2010-09-01 23:42:46 PDT
I can't reproduce the issue both on Mac and Windows...

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre

Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre
Comment 2 Kohei Yoshino [:kohei] 2010-09-01 23:48:00 PDT
Alice-san, do you use Jaegermonkey builds? If so, this might be a regression of JM. The dropdown menu is built on jQuery, FYI.
Comment 3 Alice0775 White 2010-09-02 00:32:09 PDT
(In reply to comment #2)
> Alice-san, do you use Jaegermonkey builds? If so, this might be a regression of
> JM. The dropdown menu is built on jQuery, FYI.

No, I use m-c build.And it happens with new profile.
And It  happens except the page of "アドオン" https://addons.mozilla.jp/firefox/ .

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/01fa971e62ee
Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190212
Fails:
http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa
Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190555
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa

I guess this causes landing of Bug 130078 - integrate iframe into chrome view hierarchy (link view managers / trees between chrome and content)
Comment 4 Kohei Yoshino [:kohei] 2010-09-02 03:33:36 PDT
OK, I *can* reproduce the issue on Windows XP. This is the same build as I tested on Windows 7, but the submenus cannot be selected:

Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre

(In reply to comment #3)
> And It  happens except the page of "アドオン" https://addons.mozilla.jp/firefox/ .

The dropdown menu on addons.m.j is CSS-only at this time. I've rewritten the one on m.j with jQuery to support keyboard navigation. It works if you disable JavaScript even on Windows XP.

> I guess this causes landing of Bug 130078 - integrate iframe into chrome view
> hierarchy (link view managers / trees between chrome and content)

Ok, moving the product/component.
Comment 5 Timothy Nikkel (:tnikkel) 2010-09-02 11:28:20 PDT
Probably caused by bug 587944.
Comment 6 Timothy Nikkel (:tnikkel) 2010-09-02 20:26:58 PDT
I don't know how to reproduce this. I've tried various things. Is anyone who can reproduce able to make their own builds? If so, which changeset in the range causes the problem? Most likely it would be either bug 587944 or bug 130078.
Comment 7 Alice0775 White 2010-09-03 01:35:15 PDT
(In reply to comment #6)
> I don't know how to reproduce this. I've tried various things. Is anyone who
> can reproduce able to make their own builds? If so, which changeset in the
> range causes the problem? Most likely it would be either bug 587944 or bug
> 130078.

In local build,
Revert to changeset 687b70fea4d0 : works.
Revert to changeset 7804b5cf4313 : fails.

So Changeset 7804b5cf4313( bug 130078 ) causes the problem.

It happens only on Windows XP sp3 (Classic and Luna Style).
And it does not happen on Windows 7.
Comment 8 Alice0775 White 2010-09-03 04:27:46 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > I don't know how to reproduce this. I've tried various things. Is anyone who
> > can reproduce able to make their own builds? If so, which changeset in the
> > range causes the problem? Most likely it would be either bug 587944 or bug
> > 130078.
> 
> In local build,
> Revert to changeset 687b70fea4d0 : works.
> Revert to changeset 7804b5cf4313 : fails.
> 
> So Changeset 7804b5cf4313( bug 130078 ) causes the problem.
> 
> It happens only on Windows XP sp3 (Classic and Luna Style).
> And it does not happen on Windows 7.

Oops
Sorry, it happens on Windows7 too.
Comment 9 Timothy Nikkel (:tnikkel) 2010-09-04 20:12:22 PDT
Could you try this try server build to see if the problem is fixed or not? Thanks.

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bd035cc781da/
Comment 10 Alice0775 White 2010-09-04 20:46:33 PDT
(In reply to comment #9)
> Could you try this try server build to see if the problem is fixed or not?
> Thanks.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bd035cc781da/
I tried the tryserver build with new profile.
A: On Windows XP
     The tryserver build is not fixed. The pull-down is closed immediately when I move mouse on the pull-down.

B: On Windows 7
     It fails just after loading of the page. It is OK if I wait after loading for one or two seconds. or It is OK  at the second time of pulldown.

As for the tryserver build, nothing seems to have a change from m-c build.
Comment 11 Alice0775 White 2010-09-05 09:39:39 PDT
This problem also happens on Lunux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100905 Minefield/4.0b6pre ID:20100905030701
Comment 12 Timothy Nikkel (:tnikkel) 2010-09-05 11:51:48 PDT
Alice, do you see the problem on Linux with 2010-08-27 nightlies and earlier? I found that the menu almost never stays open for me on Linux even using a 2010-08-27 nightly.

Also, thanks for testing all these different builds and even making your own builds Alice!
Comment 14 Alice0775 White 2010-09-05 22:27:12 PDT
(In reply to comment #13)
> Could you try these two try server builds? Thanks again.
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-953e476d3476/
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-1e73a253aaf9/
Both builds have same problem...



Different range on Linux build...
Works:
http://hg.mozilla.org/mozilla-central/rev/26ee1b556bd9
Mozilla/5.0 (X11; Linux i686; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre ID:20100806031556
Fails:
http://hg.mozilla.org/mozilla-central/rev/81c119fb86c7
Mozilla/5.0 (X11; Linux i686; rv:2.0b4pre) Gecko/20100807 Minefield/4.0b4pre ID:20100807025746
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=26ee1b556bd9&tochange=81c119fb86c7

Because it happens only in mozilla.jp, Is it the site issue?
Comment 15 Timothy Nikkel (:tnikkel) 2010-09-05 22:29:42 PDT
(In reply to comment #14)
> Because it happens only in mozilla.jp, Is it the site issue?

I don't know, maybe. Bug 592093 is a similar issue on a different site though.
Comment 16 Alice0775 White 2010-09-06 02:51:54 PDT
In adittionto comment #14

On the Linux:
Revert to changeset 25c871027f89 in local build, then the problems(mozilla.jp and www.google.com/mobile/) is  hard to reproduce.(Sometimes, it happens when I move mouse quickly)

So landing of 151d5caa8d5f of Bug 575336 causes the problem on Linux.
Comment 17 Timothy Nikkel (:tnikkel) 2010-09-06 19:39:01 PDT
Can you try this try server build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-c5d26ab0ec67/
Comment 18 Alice0775 White 2010-09-06 21:23:38 PDT
(In reply to comment #17)
> Can you try this try server build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-c5d26ab0ec67/
Umm, I tried it on  Windows XP, It seems to change nothing.
Comment 19 Timothy Nikkel (:tnikkel) 2010-09-06 21:32:31 PDT
That was the backout of 151d5caa8d5f applied to current trunk.

A reduced testcase would help here. I'll have to dig into this deeper.
Comment 20 Alice0775 White 2010-09-06 21:46:40 PDT
(In reply to comment #19)
> That was the backout of 151d5caa8d5f applied to current trunk.
> 
> A reduced testcase would help here. I'll have to dig into this deeper.
Can you prepare Linux 32bit build?

@Yoshino san, 
Can you prepare a reduced testcase?
Comment 21 Timothy Nikkel (:tnikkel) 2010-09-07 01:39:45 PDT
(In reply to comment #20)
> (In reply to comment #19)
> > That was the backout of 151d5caa8d5f applied to current trunk.
> Can you prepare Linux 32bit build?

Sorry, I meant to the first time, but I made a mistake. A Linux 32bit try server build of the same thing should appear in about 90 minutes at
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-a9e9e8ec6498/ (the directory is not there yet).
Comment 22 Alice0775 White 2010-09-07 02:52:24 PDT
(In reply to comment #21)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-a9e9e8ec6498/
The pull-down hides immediately, same as Windows XP.
Comment 23 Timothy Nikkel (:tnikkel) 2010-09-12 10:50:35 PDT
Can you try a 2010-09-12 nightly or later and see if anything has changed here?
Comment 24 Alice0775 White 2010-09-12 11:06:36 PDT
Not works. Nothing is changed.:

http://hg.mozilla.org/mozilla-central/rev/cd3c926a7413
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre ID:20100912030102

http://hg.mozilla.org/mozilla-central/rev/cd3c926a7413
Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre ID:20100912041924
Comment 25 Timothy Nikkel (:tnikkel) 2010-09-13 13:50:40 PDT
Boris, see comment 16. Any idea what might be going wrong here?
Comment 26 Boris Zbarsky [:bz] 2010-09-13 17:53:45 PDT
Not offhand.  :(
Comment 27 Timothy Nikkel (:tnikkel) 2010-09-15 12:36:54 PDT
Created attachment 475587 [details]
semi-reduced testcase

Still trying to reduce this further. Verifying that this reproduces the problem for other people would be good.
Comment 28 Timothy Nikkel (:tnikkel) 2010-09-16 19:54:10 PDT
Turning off all synth mouse moves fixes the problem, so we're getting a problematic synth mouse move.
Comment 29 Timothy Nikkel (:tnikkel) 2010-09-20 23:36:14 PDT
Does the reduced testcase I posted to this bug actually represent the problem people are seeing? ie does it fail and fail in the same way as the original page?
Comment 30 Alice0775 White 2010-09-20 23:58:01 PDT
(In reply to comment #29)
> Does the reduced testcase I posted to this bug actually represent the problem
> people are seeing? 
I tried the testcase  attachment 475587 [details].
It reproduce the bug on Windows XP and Linux.

>ie does it fail and fail in the same way as the original
> page?
Yes exactly.
Comment 31 mitsugu oyama 2010-09-21 02:00:35 PDT
I can not select sub-menuitem,too.
Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Comment 32 Timothy Nikkel (:tnikkel) 2010-09-21 10:45:25 PDT
(In reply to comment #31)
> I can not select sub-menuitem,too.
> Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

I was also able to reproduce, but with much less frequency, on Linux with Firefox 3.6, which confused me. I think recent changes have made this happen a lot more often on Linux and also affected Windows in a different way.
Comment 33 mitsugu oyama 2010-09-21 14:09:40 PDT
Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

I seem to be not reproduced if mouse pointer be moved very very slowly (like not be moved).
Comment 34 Timothy Nikkel (:tnikkel) 2010-09-21 22:35:24 PDT
Hmm, on Windows synth mouse moves have nothing to do with it: the problem still happens with all synth mouse moves disabled.
Comment 35 Alice0775 White 2010-09-21 23:49:02 PDT
When mouse move over submenu, "expanded" attribute is removed by mouseout event.
Which CSS should be given priority to? 
it is the former, the sub menu disappears, and if it is the latter, the sub menu does not disappear .
.js #gnav ul li:hover ul { left: -9999px; }
#gnav ul li:hover ul, .js #gnav ul li.expanded ul { left: 0; }


BTW, If remove 
.js #gnav ul li:hover ul { left: -9999px; }
The problem is gone on XP and Linux.
Comment 36 Timothy Nikkel (:tnikkel) 2010-09-21 23:58:11 PDT
(In reply to comment #35)
> When mouse move over submenu, "expanded" attribute is removed by mouseout
> event.
> Which CSS should be given priority to? 
> it is the former, the sub menu disappears, and if it is the latter, the sub
> menu does not disappear .
> .js #gnav ul li:hover ul { left: -9999px; }
> #gnav ul li:hover ul, .js #gnav ul li.expanded ul { left: 0; }

".js #gnav ul li:hover ul" and ".js #gnav ul li.expanded ul" are tied, but ".js #gnav ul li.expanded ul" comes last, so it wins if both rules match. "#gnav ul li:hover ul" loses to both the other ones.

> BTW, If remove 
> .js #gnav ul li:hover ul { left: -9999px; }
> The problem is gone on XP and Linux.

Yeah, that line just seems wrong. But we use to work with it. We should at least understand why.

We first dispatch the mouseout event, and it removes the expanded attribute, so then the rule ".js #gnav ul li:hover ul { left: -9999px; }" applies. But then the mouseover event calls focus on the <a>, which flushes the document, so the menu gets reflowed and is invisible now. Then the mouseover event bubbles and we set the expanded attribute again. But a flush is not forced. So if we get an event now it will not be over the menu anymore. On Windows at least we used to always get a paint event before anymore more mouse events. The paint event caused us to flush. Not sure why we don't anymore.
Comment 37 Boris Zbarsky [:bz] 2010-09-21 23:58:12 PDT
".js #gnav ul li:hover ul" has higher specificity than "#gnav ul li:hover ul".  So assuming all this stuff is inside something with class="js" the selector not starting with ".js" there doesn't matter.

".js #gnav ul li.expanded ul" has the same specificity as ".js #gnav ul li:hover ul" and comes later, so should win, it matches at all (that is, if the <li> has class="expanded").
Comment 38 Timothy Nikkel (:tnikkel) 2010-09-26 18:06:49 PDT
The general pattern that happens in this bug and bug 592093 is as follows. A mouse over/out event handler on a parent element sets a property on the parent element to show/hide the dropdown (display none/block in one case, class name of expanded or no class name in the other case). The actual layout changes at the next refresh driver notify, or if something else flushes before that. When the mouse moves between child elements the mouse out/over for those child elements bubbles and the property on the parent gets toggled. This is fine so far, because the dropdown is visible, and the next flush will just leave it open. But the two problem pages do something that flushes when the property on the parent element is set to make the dropdown not visible. (One calls focus on the mouseover'ed link, the other gets coords from the document to determine where to place the dropdown.) At this point if we get another mouse move before something that flushes, the mouse move will not be over the dropdown anymore because the dropdown is not visible. Before bug 130078 there always seemed to be a paint event coming from the OS before any more mouse moves (the paint flushed via WillPaint). After bug 130078, we don't always get a paint event before another mouse move. On Linux this bug is only made worse by 130078, as I can reproduce (with much less frequency) on Firefox 3.6.

So unless we can make some sort of guarantees about ordering of events, I think we have to flush after dispatching mouse over/out events.
Comment 39 Timothy Nikkel (:tnikkel) 2010-09-26 18:35:47 PDT
Created attachment 478692 [details] [diff] [review]
patch
Comment 40 Olli Pettay [:smaug] 2010-09-27 02:35:03 PDT
So before bug 130078 we got always a flush before mousemove? Even with synthetic
mousemove? Should we flush before mousemove? (That would be rather unfortunate).

Actually, what would happen if mouseover/out listeners wouldn't be used, but 
mousemove? Would this bug still happen in that case?
Should we flush always before any mouse event?
Comment 41 Timothy Nikkel (:tnikkel) 2010-09-27 12:13:05 PDT
(In reply to comment #40)
> So before bug 130078 we got always a flush before mousemove? Even with
> synthetic mousemove?

Well, on Windows, on these two sites, we always had a paint event before processing the next mouse event, and the paint event flushed. I _think_ we were just getting lucky, and no one planned for that behaviour. On Linux we've had this problem since before bug 130078, and it is even in Firefox 3.6, but with less frequency.

> Actually, what would happen if mouseover/out listeners wouldn't be used, but 
> mousemove? Would this bug still happen in that case?

The unique thing about mouseover/out that doesn't apply to mousemoves is that parent elements get a mouseout and mouseover whenever the mouse is moved between two child elements.

> Should we flush before mousemove? (That would be rather unfortunate).
> Should we flush always before any mouse event?

I agree that it would be unfortunate, so I tried to avoid doing it. If we later find problems that would be solved by this then we can revisit this.
Comment 42 Olli Pettay [:smaug] 2010-09-28 01:00:01 PDT
(In reply to comment #41)
> The unique thing about mouseover/out that doesn't apply to mousemoves is that
> parent elements get a mouseout and mouseover whenever the mouse is moved
> between two child elements.

So? What if the mouse isn't moved between any elements, just inside an element.

> I agree that it would be unfortunate, so I tried to avoid doing it. If we later
> find problems that would be solved by this then we can revisit this.
Atm I don't see any reason why we don't have the problem with mousemove events.
Comment 43 Olli Pettay [:smaug] 2010-09-28 04:25:50 PDT
Comment on attachment 478692 [details] [diff] [review]
patch

r- until the patch is fixed to cover also mousemove, or it is explained why
mousemove doesn't need the fix.
Comment 44 Timothy Nikkel (:tnikkel) 2010-09-29 00:50:31 PDT
smaug, do you think that flushing for all mouse moves is a good idea? Can you think of a different/better way to fix this?
Comment 45 Olli Pettay [:smaug] 2010-10-05 01:43:29 PDT
I can't really think of any better way to fix this :(
Comment 46 Olli Pettay [:smaug] 2010-10-05 01:45:12 PDT
Or hmm, should we flush only if the frame under mouse is marker to need reflow or something?
Comment 47 Olli Pettay [:smaug] 2010-10-05 01:46:54 PDT
Or, does bug 601547 help here?
Comment 48 Olli Pettay [:smaug] 2010-10-05 01:49:00 PDT
Apparently it does
https://bugzilla.mozilla.org/show_bug.cgi?id=601547#c13
Comment 49 Timothy Nikkel (:tnikkel) 2010-10-06 16:26:04 PDT
Should be fixed (on Windows) by bug 601547.
Comment 50 Timothy Nikkel (:tnikkel) 2010-10-06 18:46:03 PDT
Had to back out bug 601547.
Comment 51 Timothy Nikkel (:tnikkel) 2010-10-08 12:16:10 PDT
Landed bug 601547 again so this should be fixed (on Windows) by bug 601547 again.
Comment 52 Alice0775 White 2010-10-09 22:54:13 PDT
I filed Bug 603150 for linux
Comment 53 Karl Tomlinson (ni?:karlt) 2010-10-10 17:57:20 PDT
Can the mochitest be pushed (at least for fixed platforms)?
Comment 54 Timothy Nikkel (:tnikkel) 2010-10-10 18:10:52 PDT
I initially thought it wouldn't pass with the different fix for this bug, but now I think it might. I'll put it in my queue for next time I push to try.
Comment 55 Timothy Nikkel (:tnikkel) 2010-10-11 12:53:39 PDT
The test fails on all platforms.

Note You need to log in before you can comment on or make changes to this bug.