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

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Alice0775 White]

Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101008 Firefox/4.0b8pre ID:20101008025833

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 pointer into the
pull down menu.

This is simular to Bug 592954 for Windows. 
But this is Linux specific problem now.

Reproducible: Always

Steps to Reproduce:
1.Open Minefield
2.Open ( http://mozilla.jp/ )
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

Regression Window:
Works:
http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090610 Namoroka/3.6a1pre ID:20090610032721
Fails:
http://hg.mozilla.org/mozilla-central/rev/4430cae50dad
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090611 Namoroka/3.6a1pre ID:20090611031057
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d3e6d2cbb9&tochange=4430cae50dad

Comment 1

[Timothy Nikkel (:tnikkel)]

Bug 602303 should fix this.

Comment 2

[Karl Tomlinson (:karlt)]

Relying on the order of paint events might help, but doesn't sound like it really addresses the bug.

Assuming this is similar to the test in attachment 478692 [details] [diff] [review], I wonder if the real bug is in the event handler not checking the original event target.

However, if the web content is expecting that style changes are effectively processed synchronously wrt events, and we think that is a reasonable assumption, then we should address that directly.

It makes sense to me not to unnecessarily flush layout before real mouse events, though, because the user only ever saw the unflushed layout.

And I'm struggling to come up with sensible suggestions on how to decide whether to flush layout.

I wonder whether it would make sense to think of all operations that take place during processing of a single event as part of one transaction.  If part of the transaction happens (i.e. layout is flushed), then the transaction should be completed (probably most easily at the end of the event processing, but possibly before the next event).

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> Assuming this is similar to the test in attachment 478692 [details] [diff] [review], I wonder if the real
> bug is in the event handler not checking the original event target.
Which event handler? Since there is no anonymous content involved
event.target == event.originalTarget.







> I wonder whether it would make sense to think of all operations that take place
> during processing of a single event as part of one transaction.  If part of the
> transaction happens (i.e. layout is flushed), then the transaction should be
> completed (probably most easily at the end of the event processing, but
> possibly before the next event).
The can be new new events dispatched during dispatching an event, and
event handlers may flush layout any number times.
So it is not clear to me what you mean with "transaction" in this context.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to comment #3)
> (In reply to comment #2)
> > Assuming this is similar to the test in attachment 478692 [details] [diff] [review] [details], I wonder if the real
> > bug is in the event handler not checking the original event target.
> Which event handler? Since there is no anonymous content involved
> event.target == event.originalTarget.

I meant the event handler on the "container" changing the "expanded" attribute.

But are you effectively saying that there's actually no way for a page to distinguish between the events from the mouse leaving a child ("item") element and those when the mouse leaves the "container" element?

> So it is not clear to me what you mean with "transaction" in this context.

Yeah, perhaps there isn't a clear transaction.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #4)
> But are you effectively saying that there's actually no way for a page to
> distinguish between the events from the mouse leaving a child ("item") element
> and those when the mouse leaves the "container" element?
Sounds like you're talking about .currentTarget vs. .target
not .originalTarget vs. .target.
So yes, web page can check what is the .target and whether it is the same
as .currentTarget.

Comment 6

[Alice0775 White]

I cannot reproduce any more.
Maybe the site fixed the problem.