Closed Bug 592954 Opened 14 years ago Closed 14 years ago

Can not select sub-menuitem in pull down menu at the top of page

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: alice0775, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(2 files)

semi-reduced testcase
3.36 KB, text/html
Details
patch
6.08 KB, patch
smaug
: review-
Details | Diff | Splinter Review 
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
URL: http://www.mozilla.jp/
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
URL: http://www.mozilla.jp/ → http://mozilla.jp/
Alice-san, do you use Jaegermonkey builds? If so, this might be a regression of JM. The dropdown menu is built on jQuery, FYI.
(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)
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.
Assignee: kohei.yoshino.bugs → nobody
Blocks: 130078
Component: www.mozilla.jp → Layout: View Rendering
Keywords: regression
Product: Websites → Core
QA Contact: www-mozilla-jp → layout.view-rendering
Version: unspecified → Trunk
Probably caused by bug 587944.
Blocks: 587944
No longer blocks: 130078
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 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.
Blocks: 130078
No longer blocks: 587944
(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.
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/
(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.
This problem also happens on Lunux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100905 Minefield/4.0b6pre ID:20100905030701
OS: Windows XP → All
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!
(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?
(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.
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.
(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.
That was the backout of 151d5caa8d5f applied to current trunk.

A reduced testcase would help here. I'll have to dig into this deeper.
(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?
(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).
(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.
Can you try a 2010-09-12 nightly or later and see if anything has changed here?
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
Boris, see comment 16. Any idea what might be going wrong here?
Not offhand.  :(
Attached file semi-reduced testcase — 
Still trying to reduce this further. Verifying that this reproduces the problem for other people would be good.
Turning off all synth mouse moves fixes the problem, so we're getting a problematic synth mouse move.
blocking2.0: --- → ?
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?
(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.
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
(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.
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).
Hmm, on Windows synth mouse moves have nothing to do with it: the problem still happens with all synth mouse moves disabled.
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.
(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.
".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").
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.
Attached patch patch — — Splinter Review 

        Attachment #478692 -
        Flags: review?(Olli.Pettay)

    
    

    
  
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?

    
    

    
  
(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.

    
    

    
  
(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 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.

        Attachment #478692 -
        Flags: review?(Olli.Pettay) → review-

    
    

    
  
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?
Whiteboard: [needs review]

    
    

    
  
I can't really think of any better way to fix this :(

    
    

    
  
Or hmm, should we flush only if the frame under mouse is marker to need reflow or something?

    
    

    
  
Or, does bug 601547 help here?

    
  
Depends on: 601547

    
    

    
  
Should be fixed (on Windows) by bug 601547.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED

    
    

    
  
Had to back out bug 601547.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Landed bug 601547 again so this should be fixed (on Windows) by bug 601547 again.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED

    
    

    
  
I filed Bug 603150 for linux

    
    

    
  
Can the mochitest be pushed (at least for fixed platforms)?
Flags: in-testsuite?

    
    

    
  
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.

    
    

    
  
The test fails on all platforms.
Flags: in-testsuite?
Component: Layout: View Rendering → Layout: Web Painting

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: