969222 - [OMT Animations] Popups of HTML selects don't grab the mouse

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Joseph Yasi]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140205001357

Steps to reproduce:

Enable OMTC layer acceleration on Linux by setting layers.acceration.force-enabled=true and layers.offmainthreadcomposition.enabled=true. Also, set environment variable MOZ_USE_OMTC=1.

Navigate to a webpage with an HTML select drop down (such as a bugzilla page). Click on the drop down with the mouse. Try to select an option in the drop down.


Actual results:

The drop down shows the options. However, mousing over them does not give focus to the options, and clicking on them does not select a new option.


Expected results:

The select box should have received focus.

Comment 1

[Joseph Yasi]

This also happens with Nightly.

Comment 2

[Eamon Nerbonne]

This also happens on windows with offmainthreadcomposition on.

Comment 3

[Eamon Nerbonne]

To be more precise: this happens on win 8.1; FF Nightly
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Build ID: 20140208030207

Comment 4

[Eamon Nerbonne]

Sorry about the flag needinfo; I accidentally left that checked while testing this very bug - clearing now!

I'll stop spamming this bug after this post.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

per the comments.

Comment 6

[KENZ (Kenji Irie)]

This bug happens when both of following preferences are true:
 * layers.offmainthreadcomposition.async-animations
 * layers.offmainthreadcomposition.enabled
on all platforms.

Regression range is:
 OK Build Built from http://hg.mozilla.org/mozilla-central/rev/298f262f21ff
 NG Build Built from http://hg.mozilla.org/mozilla-central/rev/61fd0f987cf2

Comment 7

[Alice0775 White]

Regression with both of following preferences are true
layers.offmainthreadcomposition.async-animations
layers.offmainthreadcomposition.enabled

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3e17b97b0c9a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140117192727
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/b07b7fca7f6c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140117202328
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e17b97b0c9a&tochange=b07b7fca7f6c

Regressed by: Bug 914847

Comment 8

[Joseph Yasi]

(In reply to Alice0775 White from comment #7)
> Regression with both of following preferences are true
> layers.offmainthreadcomposition.async-animations
> layers.offmainthreadcomposition.enabled
> 
> Regression window(m-i)
> Good:
> http://hg.mozilla.org/integration/mozilla-inbound/rev/3e17b97b0c9a
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
> ID:20140117192727
> Bad:
> http://hg.mozilla.org/integration/mozilla-inbound/rev/b07b7fca7f6c
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
> ID:20140117202328
> Pushlog:
> http://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=3e17b97b0c9a&tochange=b07b7fca7f6c
> 
> Regressed by: Bug 914847

I can confirm that reverting this patch set fixes the problem.

Comment 9

[Brian Birtles (:birtles)]

Sounds like bug 995591 comment 1.

Given this only occurs when layers.offmainthreadcomposition.async-animations is true, and it is false by default, I don't think this should be marked as affecting firefox31 etc.

Comment 10

[Joseph Morrill]

I can confirm this bug is still active in Firefox 30.0 with OMTC *disabled* (by defaults):
layers.offmainthreadcomposition.enabled - default (false)
layers.offmainthreadcomposition.async-animations - default (false)

The computer is a Windows 7 64-bit Intel machine, and appears to be running the "Funnelcake April 2013 Mozilla21 - 1.0" build.

On my Intel desktop running Windows 2008R2 64-bit, Firefox does *not* have this problem. OMTC is still disabled. I noticed that my desktop does not seem to be the "Funnelcake" build. The about window simply states that it is version 30.0. I don't know anything about the "Funnelcake" build, so I don't know if it's got a different code branch or not, but I figured that might be worth noting.

As mentioned in <a href='https://bugzilla.mozilla.org/show_bug.cgi?id=995591'>bug 995591</a>, holding the mouse button down while opening the select does allow me to select an option, but if I click to open the select menu, I can not select an option with the mouse (keyboard does work to select in all scenarios).

Comment 11

[avada]

(In reply to Joseph Yasi from comment #8)
> > Regressed by: Bug 914847
> 
> I can confirm that reverting this patch set fixes the problem.

Can't someone actually unbreak this? The exact cause is actually identified...

Comment 12

[Eamon Nerbonne]

If I understand correctly this bug is actually once about off-main-thread-animations, not composition, right?

Should it be added as a blocker to 980770?

Comment 13

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

comment 0, comment 6, and comment 10 all give different set of conditions, so I really don't know.

Comment 14

[Eamon Nerbonne]

I suspect that comment 0 may have simply overlooked async-animations; or perhaps back then that wasn't a separate pref?

Comment 15

[Eamon Nerbonne]

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #13)
> comment 0, comment 6, and comment 10 all give different set of conditions,
> so I really don't know.

I can still reproduce this with async-animations and omtc ON, but cannot with just OMTC on (win8.1).  A month or two ago on a linux machine I believe I observed the same behavior; so it's unlikely to be very machine sensitive. Based on your uncertainty I'm assuming you do not observe this behavior?

Comment 16

[Joseph Yasi]

(In reply to Eamon Nerbonne from comment #14)
> I suspect that comment 0 may have simply overlooked async-animations; or
> perhaps back then that wasn't a separate pref?

Yes, async-animations is required to reproduce.

Comment 18

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't adjust frame point unless it's a touch event

Bug 780692 (part 2) [1] initially added the code to adjust the frame pointer, but only if it was a touch event. I'm not actually sure why this was added, it doesn't really make sense to me.

Bug 914847 [2] changed it so we call GetNearestFrameContainingPresShell for all event types (and also flushes for all event types) which is why this regressed.

Walking up the view tree for a popup is crossing into the parent document and hit testing no longer works.

This patch just reverts to our previous behaviour for this, but we might be able to do better.

[1] https://hg.mozilla.org/mozilla-central/rev/1bc40cb5b27c
[2] https://hg.mozilla.org/mozilla-central/rev/1c63f67bbaf1

Comment 19

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

Comment on attachment 8467469 [details] [diff] [review]
Don't adjust frame point unless it's a touch event

As far as see, and scriptBlocker hints strongly about that, after
GetRootPresShell()->GetDocument()->
  EnumerateSubDocuments(FlushThrottledStyles, nullptr);
frame might point to a deleted object and when we later do
frame->PresContext(), we'd just crash.

Comment 20

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't adjust frame pointer unless it's been deleted

Ok, well if frame was a dropdown, then presShell->GetViewManager()->GetRootView() will return a view that is outside of the dropdown, and we'll hit test the main document, not the popup.

How about only adjusting the frame pointer if the previous one died? This should work as long as frame is always the root frame of the popup (nsListControlFrame in this case).

Comment 21

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c7089f9065da

Comment 22

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c7089f9065da

Comment 23

[avada]

Is there any reason this shouldn't be in FF32?
Tried aurora/beta8. It has async animations and omtc (disabled by default), but the context menu is still broken if async animations is enabled.
One might try using firefox with AA enabled, if weren't for the context menu issue. And maybe run into some bugs that otherwise would go unnoticed. (Using nightly for day to day browsing would be quite tough.)