Closed Bug 1533948 Opened 9 months ago Closed 6 months ago

[Fission] Make BrowserTabChild ready for Fission

Categories

(Firefox :: General, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 69
Fission Milestone M3
Tracking Status
firefox69 --- fixed

People

(Reporter: Felipe, Assigned: enndeakin)

References

(Depends on 2 open bugs, Blocks 1 open bug)

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

Fission Milestone: --- → M2
Assignee: nobody → felipc
Status: NEW → ASSIGNED

Original patch by Mike Conley from another bug. Cleaned it up and incorporated here

Attachment #9061117 - Attachment description: Bug 1533948 - Port PointerLock to the new actor → Bug 1533948 - Port first MozAfterPaint to the new actor

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.

Assignee: felipc → nobody
Status: ASSIGNED → NEW

Hey Neil, are you okay to pick this one up from Felipe?

Flags: needinfo?(enndeakin)

I think I have figured out what to do here.

Assignee: nobody → enndeakin
Flags: needinfo?(enndeakin)

Depends on D30030

Depends on D30032

Depends on D30034

Depends on D30037

Depends on D30040

Depends on D30045

Depends on D30048

Depends on D30053

Depends on D30055

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.

Fission Milestone: M2 → M3

Nika, do you know why the issues above might be occurring (random null objects, crash,...), or who I should ask?

Flags: needinfo?(nika)
Status: NEW → ASSIGNED
Depends on: 1550613

(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.

Flags: needinfo?(nika)
Depends on: 1523638
Attachment #9062932 - Attachment is obsolete: true
Attachment #9062929 - Attachment is obsolete: true
Attachment #9062926 - Attachment is obsolete: true
Attachment #9062924 - Attachment is obsolete: true
Attachment #9062922 - Attachment is obsolete: true
Attachment #9062938 - Attachment is obsolete: true
Attachment #9062942 - Attachment is obsolete: true
Attachment #9062944 - Attachment is obsolete: true
Attachment #9062947 - Attachment is obsolete: true
Attachment #9062949 - Attachment is obsolete: true
Attachment #9062950 - Attachment is obsolete: true
Depends on: 1556809

Note that the patch here includes hack for the Browser:AppTab message due to bug 1523638.

Depends on: 1557118
Pushed by neil@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/61dee4121753
change BrowserTabChild to inherit from JSWindowActor, r=mconley
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69

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

Regressions: 1563495
Regressions: 1563498
Regressions: 1580506
Depends on: 1582054
You need to log in before you can comment on or make changes to this bug.