1495588 - UAWidgetsChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser>)

Status: RESOLVED FIXED

(Core :: XBL, defect, P2)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: test

Apparently, browser-content.js is loaded again when <iframe mozbrowser> is created.

This can be tested by:

1. Applying the test patch, do an artifact build, package, install
2. run a mochitest that creates <iframe mozbrowser> like dom/browser-element/mochitest/test_browserElement_inproc_ContextmenuEvents.html
3. Open another console and observe |adb logcat|

Perhaps ActorManagerChild.jsm should just check if the group is attached and be done with it? Or it is better to find the cause here...

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I can get a backtrace in JS by |throw|ing things to logcat, which is

E/GeckoConsole(21589): [JavaScript Error: "Error: Why attach() is called again? attach@resource://gre/modules/ActorManagerChild.jsm:247:19
E/GeckoConsole(21589): @chrome://global/content/browser-content.js:14:1
E/GeckoConsole(21589): createIframe@http://mochi.test:8888/tests/dom/browser-element/mochitest/browserElement_ContextmenuEvents.js:303:3
E/GeckoConsole(21589): runTests@http://mochi.test:8888/tests/dom/browser-element/mochitest/browserElement_ContextmenuEvents.js:13:3
E/GeckoConsole(21589): unlockTestReady@http://mochi.test:8888/tests/dom/browser-element/mochitest/browserElementTestHelpers.js:47:7
E/GeckoConsole(21589): _resolveAndCallOptionalCallback@resource://specialpowers/specialpowersAPI.js:1054:7

I guess I will need to find a way to extract C++ backtrace. I wonder how many people has Fennec debug environment these days...

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

With more modification to the test patch, I can see that we are receiving different message manager for each of the attach() call. Perhaps the question is not why frame script is loaded again, but rather, how to properly segregate two event listeners in the same process so they could manage their own frames?

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Alright, I should handle the case in UAWidgetChild instead, given that having multiple message managers is indeed the norm and they can be nested in the event propagation hierarchy.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

But that didn't explain why the same test case didn't fail on desktop though. Do we run/setup mozbrowser iframe different between applications?

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #4)
> But that didn't explain why the same test case didn't fail on desktop
> though. Do we run/setup mozbrowser iframe different between applications?

Right, because <video> with no controls will not have a widget installed.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Bug 1495588 - Prevent the parent frame from getting handled UA Widget events

This can happen when the message manager is associated to an embedded frame,
like an <iframe mozbrowser>.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/edfd1b8910f6
Prevent the parent frame from getting handled UA Widget events r=kmag,smaug

Comment 8

[Cosmin Sabou [:CosminS]]

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