Closed
Bug 961863
Opened 11 years ago
Closed 11 years ago
[e10s] Update browser remoteness attribute when restoring a tab
Categories
(Firefox :: Session Restore, defect)
Tracking
()
RESOLVED
FIXED
Firefox 29
People
(Reporter: billm, Assigned: billm)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
7.11 KB,
patch
|
Felipe
:
review+
|
Details | Diff | Splinter Review |
Each time we load a new URL, we have to decide whether to load it in a content process or in the main process. Most of the time we use a content process, but for about: URLs we usually use the main process. That makes it a lot easier to get chrome pages like about:memory and about:support to work.
Session restore doesn't go through the same paths to load URLs, and so it misses the _updateBrowserRemoteness call. The consequence is that the first tab is usually restored in the main process even if it's for a normal content URL. This patch fixes the problem.
Attachment #8362713 -
Flags: review?(ttaubert)
Attachment #8362713 -
Flags: review?(felipc)
Comment 1•11 years ago
|
||
Comment on attachment 8362713 [details] [diff] [review]
update-remoteness
Review of attachment 8362713 [details] [diff] [review]:
-----------------------------------------------------------------
::: browser/base/content/tabbrowser.xml
@@ +1413,5 @@
> + <!--
> + We're about to load aURL into aBrowser. This function ensures
> + that the remote attribute is set correctly for aBrowser.
> + -->
> + <method name="prepareBrowserForURL">
Should we maybe just expose _updateBrowserRemoteness() and rename it to gBrowser.updateBrowserRemoteness() and let it take the URL as the second parameter? That seems somehow more expressive to me than somehow preparing the browser for something :)
::: browser/components/sessionstore/src/SessionStore.jsm
@@ +2747,5 @@
>
> + let activePageData = tabData.entries[activeIndex] || null;
> + let uri = activePageData ? activePageData.url || null : null;
> +
> + tabbrowser.prepareBrowserForURL(browser, uri);
Can you please add a short comment here that says in e10s we're going to make it a remote browser if possible?
Attachment #8362713 -
Flags: review?(ttaubert) → review+
Comment 2•11 years ago
|
||
Comment on attachment 8362713 [details] [diff] [review]
update-remoteness
Review of attachment 8362713 [details] [diff] [review]:
-----------------------------------------------------------------
yeah I like tim's suggestion
Attachment #8362713 -
Flags: review?(felipc)
Assignee | ||
Comment 3•11 years ago
|
||
OK, how about this?
Attachment #8362713 -
Attachment is obsolete: true
Attachment #8362732 -
Flags: review?(felipc)
Updated•11 years ago
|
Attachment #8362732 -
Flags: review?(felipc) → review+
Assignee | ||
Comment 4•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
You need to log in
before you can comment on or make changes to this bug.
Description
•