Closed
Bug 1495588
Opened 6 years ago
Closed 6 years ago
UAWidgetsChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser>)
Categories
(Core :: XBL, defect, P2)
Core
XBL
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: timdream, Assigned: timdream)
References
Details
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/x-phabricator-request
|
Details |
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...
Assignee | ||
Comment 1•6 years ago
|
||
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...
Assignee | ||
Comment 2•6 years ago
|
||
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?
Assignee | ||
Comment 3•6 years ago
|
||
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.
Component: Async Tooling → XBL
Product: Toolkit → Core
Summary: ActorManagerChild.attach() is called again when a <iframe mozbrowser> is created in Fennec → UAWidgetChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser> created in Fennec)
Assignee | ||
Updated•6 years ago
|
Summary: UAWidgetChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser> created in Fennec) → UAWidgetsChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser> created in Fennec)
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Assignee | ||
Comment 6•6 years ago
|
||
This can happen when the message manager is associated to an embedded frame,
like an <iframe mozbrowser>.
Assignee | ||
Updated•6 years ago
|
Summary: UAWidgetsChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser> created in Fennec) → UAWidgetsChild should prevent the parent frame from getting handled events (e.g. in <iframe mozbrowser>)
Updated•6 years ago
|
Priority: -- → P2
Pushed by tchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/edfd1b8910f6
Prevent the parent frame from getting handled UA Widget events r=kmag,smaug
Comment 8•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•