Closed Bug 961863 Opened 9 years ago Closed 9 years ago

[e10s] Update browser remoteness attribute when restoring a tab

Categories

(Firefox :: Session Restore, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 29

People

(Reporter: billm, Assigned: billm)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Attached patch update-remoteness (obsolete) — 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 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 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)
OK, how about this?
Attachment #8362713 - Attachment is obsolete: true
Attachment #8362732 - Flags: review?(felipc)
Attachment #8362732 - Flags: review?(felipc) → review+
https://hg.mozilla.org/mozilla-central/rev/a23749908ea1
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
You need to log in before you can comment on or make changes to this bug.