[Fission] Make BrowserTabChild ready for Fission
Categories
(Firefox :: General, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: Felipe, Assigned: enndeakin)
References
Details
Attachments
(6 files, 11 obsolete files)
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review |
Make the code in BrowserTabChild.jsm ready to work with out-of-process iframes
| Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
|
||
Original patch by Mike Conley from another bug. Cleaned it up and incorporated here
| Reporter | ||
Comment 2•2 years ago
|
||
| Reporter | ||
Comment 3•2 years ago
|
||
| Reporter | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
| Reporter | ||
Comment 5•2 years ago
|
||
| Reporter | ||
Comment 6•2 years ago
|
||
So what I did to help the conversion was to make a copy of BrowserTabChild and call it BrowserTabChild2.jsm. That way, I could be porting part of the features to the new actor, while keep the remaining ones working through the legacy actor.
The patch queue ported all the functionality going from the child to parent. There are some comments that I left that are good gotchas to be aware of, and probably should be filed as bugs for improvements on the API.
Hey Neil, are you okay to pick this one up from Felipe?
| Assignee | ||
Comment 8•2 years ago
|
||
I think I have figured out what to do here.
| Assignee | ||
Comment 9•2 years ago
|
||
| Assignee | ||
Comment 10•2 years ago
|
||
Depends on D30030
| Assignee | ||
Comment 11•2 years ago
|
||
Depends on D30032
| Assignee | ||
Comment 12•2 years ago
|
||
Depends on D30034
| Assignee | ||
Comment 13•2 years ago
|
||
Depends on D30037
| Assignee | ||
Comment 14•2 years ago
|
||
Depends on D30040
| Assignee | ||
Comment 15•2 years ago
|
||
Depends on D30045
| Assignee | ||
Comment 16•2 years ago
|
||
Depends on D30048
| Assignee | ||
Comment 17•2 years ago
|
||
Depends on D30050
| Assignee | ||
Comment 18•2 years ago
|
||
Depends on D30053
| Assignee | ||
Comment 19•2 years ago
|
||
Depends on D30055
| Assignee | ||
Comment 20•2 years ago
|
||
The patches here seem to mostly work in some cases. Random failures occur while browsing with these patches applied, such as null frame loaders, null documents and so forth.
You can see some of these issues on browser tests:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8eaceec194f23a9be588b390d96fcc619eec7203
Some can be reproduced when running the tests locally, others can be seen randomly while browsing.
A crash will occur if opening about:config at https://searchfox.org/mozilla-central/source/dom/ipc/JSWindowActorChild.cpp#46 because mParent is null.
Updated•2 years ago
|
| Assignee | ||
Comment 21•2 years ago
|
||
Nika, do you know why the issues above might be occurring (random null objects, crash,...), or who I should ask?
| Assignee | ||
Updated•2 years ago
|
Comment 22•2 years ago
|
||
(In reply to Neil Deakin from comment #20)
The patches here seem to mostly work in some cases. Random failures occur while browsing with these patches applied, such as null frame loaders, null documents and so forth.
That's interesting. If you can isolate a situation where you're finding one of these is null unexpectedly it would be good to know. I tried looking at some of the issues behind the link and wasn't able to glean too much off of them, as they mostly looked like timeouts, and I didn't see any obvious JS errors being raised due to a null pointer in my quick scan.
A crash will occur if opening about:config at https://searchfox.org/mozilla-central/source/dom/ipc/JSWindowActorChild.cpp#46 because mParent is null.
Oops, that is 100% our bad. I've got some patches up in bug 1550613 which should make that issue go away.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 23•2 years ago
|
||
| Assignee | ||
Comment 24•2 years ago
|
||
Note that the patch here includes hack for the Browser:AppTab message due to bug 1523638.
Comment 25•2 years ago
|
||
Pushed by neil@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/61dee4121753 change BrowserTabChild to inherit from JSWindowActor, r=mconley
Comment 26•2 years ago
|
||
| bugherder | ||
Comment 27•2 years ago
|
||
got some of these:
JavaScript error: resource:///actors/BrowserTabParent.jsm, line 32: TypeError: undefined has no properties
JavaScript error: , line 0: NS_ERROR_UNEXPECTED:
JavaScript error: resource:///actors/BrowserTabParent.jsm, line 27: TypeError: undefined is not a function
JavaScript error: , line 0: NS_ERROR_UNEXPECTED:
JavaScript error: resource:///actors/BrowserTabParent.jsm, line 27: TypeError: undefined is not a function
JavaScript error: , line 0: NS_ERROR_UNEXPECTED:
JavaScript error: resource:///actors/BrowserTabParent.jsm, line 32: TypeError: undefined has no properties
JavaScript error: , line 0: NS_ERROR_UNEXPECTED:
./browser/actors/BrowserTabParent.jsm:
switch (message.name) {
case "Browser:WindowCreated": {
gBrowser.announceWindowCreated(browser, message.data.userContextId); // line 27
break;
}
case "Browser:FirstPaint": {
browser.ownerGlobal.gBrowserInit._firstBrowserPaintDeferred.resolve(); // line 32
break;
}
firefox used:
changeset: 479096:9b4c8fb46d85
tag: tip
parent: 479094:e593e11eff08
parent: 479095:adc12b4c5a9d
date: Tue Jun 18 07:10:14 2019 +0300
summary: Merge inbound to mozilla-central. a=merge
Updated•2 years ago
|
Description
•