59 bytes, text/x-review-board-request
See bug 1328829, comment 17. We should rename relatedBrowser to something better.
Along with renaming it, could we change to storing the nsIFrameLoader for the content, instead of nsIBrowser (which we currently retrieve the frame loader from in `GetContentParent`)? For the case of Responsive Design Mode and View Source in bug 1333914, it would be easier to pass around the frame loader for the content because it's loaded in an <iframe mozbrowser>, not a <xul:browser>. If that seems okay, we could name the property something like "sameProcessAsFrameLoader".
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1) > Along with renaming it, could we change to storing the nsIFrameLoader for > the content, instead of nsIBrowser I *think* this should work, but I'm not sure. In particular, I don't know if doing this will force us to create a frame loader for browser elements too early (see tabbrowser._createBrowser) or even if that would be a problem. > If that seems okay, we could name the property something like > "sameProcessAsFrameLoader". That sounds fine to me.
Assignee: nobody → jryans
Status: NEW → ASSIGNED
In manual testing, view source tabs and windows continue to work as expected with e10s-multi.
Comment on attachment 8837293 [details] Bug 1335281 - Use frame loader for same process browsers. https://reviewboard.mozilla.org/r/112454/#review113886
Attachment #8837293 - Flags: review?(mrbkap) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/a273874c2205 Use frame loader for same process browsers. r=mrbkap
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox54: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
You need to log in before you can comment on or make changes to this bug.