Closed Bug 1324359 Opened 7 years ago Closed 7 years ago

Consider renaming DocShell's process lock stuff to something more understandable

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: freesamael, Assigned: nika)

References

Details

Attachments

(1 file, 1 obsolete file)

Based on review comment in bug 1315105 comment 42:

> >+  // Adopting an out-of-process prerendered document is conceptually similar to
> >+  // switching dochshell's process, since it's the same browsing context from
> >+  // other browsing contexts' perspective. If we're locked in current process,
> >+  // we can not prerender out-of-process.
> >+  if (docShell->GetIsProcessLocked()) {
> It is still rather unclear what "locked" means in this context.
> Could you please file a followup to rename "locked" to something
> understandable.

We may want to find a better name for the process lock stuff.
Priority: -- → P3
DocShells are always "locked" to a certain process, so the explanation in 
http://searchfox.org/mozilla-central/rev/f680e72cc6579f90b992b63ca14d923d2afea612/docshell/base/nsIDocShell.idl#1107 is rather weird.
Wouldn't something like "[infallible] readonly attribute unsigned long allowNextLoadInDifferentProcess;"
be closer to what the attribute actually is about.
The consts would need to be renamed then too. Something like ALLOW; and DENY_IN_IFRAME, DENY_HAS_RELATED_CONTEXTS, DENY_NOT_CHILD_PROCESS
I tried renaming & simplifying the concept in this commit. I'd love both of your inputs on this.

MozReview-Commit-ID: JTp8Q2mWqpN
Attachment #8822530 - Flags: review?(sawang)
Attachment #8822530 - Flags: review?(bugs)
Comment on attachment 8822530 [details] [diff] [review]
Rename and simplify the DocShell ProcessLock concept

Should it be NonDependent, not Nondependent ?

What does 'content reference' mean, in particular, what does "content" mean in this context? Is it same as "browsing context" / docshells like the comment then seems to hint.

And why "non" in the name. Perhaps my English is bad, but I would think that hasDependentContentReferences means that there are such references, which prevent use of a new process. (but "content" is still mystery)

What does the following mean
"+   * This value is `true` if there exist docshells within this docshell's unit
+   * of related browsing contexts which would outlive a navigation load"
Does it mean that if there are child docshells and the current top level page will enter bfcache, the property is true?


Sorry, not clear enough to me, at least not at 3am.

Would hasDependentBrowsingContextReferences work?
Attachment #8822530 - Flags: review?(bugs) → review-
(In reply to Olli Pettay [:smaug] from comment #3)
> Comment on attachment 8822530 [details] [diff] [review]
> Rename and simplify the DocShell ProcessLock concept
> 
> Should it be NonDependent, not Nondependent ?
>
> What does 'content reference' mean, in particular, what does "content" mean
> in this context? Is it same as "browsing context" / docshells like the
> comment then seems to hint.

What I meant by a content reference was that web content has a reference to this docshell's browsing context, either through an iframe, or .opener. 

When I was meaning by "NonDependent" was referring to such a reference which would not be destroyed by the navigation. For example, if a document has an iframe inside of it, that iframe has a reference to the given document through .parent, but we don't need to worry about that reference because that iframe "depends" on the document in question to exist. 

Perhaps a better wording would be HasNonFrameContentVisibleReferences? I could also call it something like TabGroupHasOtherToplevelWindows() which also communicates the idea I would think.

The negation could be IsOnlyToplevelInTabGroup()?

I'm sure there is a better name for this method. I'd love some feedback on my explanation and ideas.
Flags: needinfo?(bugs)
oh, TabGroupHasOtherToplevelWindows() might be quite good one, and/or IsOnlyToplevelInTabGroup().
Flags: needinfo?(bugs)
Updated version with the new name.
Attachment #8823380 - Flags: review?(bugs)
Attachment #8822530 - Attachment is obsolete: true
Attachment #8822530 - Flags: review?(sawang)
Comment on attachment 8823380 [details] [diff] [review]
Rename and simplify the DocShell ProcessLock concept

>+   * This value is `true` if its corresponding unit of related browsing contexts
>+   * (TabGroup) contains only 1 toplevel window, and that window is the outer
>+   * window corresponding to this docshell. This is the case when the current
>+   * document is loaded within an iframe, and when this window was either opened
>+   * by, or has opened another document with, window.open.
I don't understand the sentence starting "This is the case..."
Almost if you started to describe the 'false' case here. Please fix


>    *
>-   * NOTE: Some loads may not consider this a hard process lock, and may wish to
>-   * ignore this reason.
>+   * If this value is `false`, it would be content-visible for a load occuring
>+   * in this docshell to be performed within a different docshell.
perhaps 'web content visible' or so


>+  // Adopting an prerendered document is similar to performing a load within a
>+  // different docshell, as the prerendering must have occured in a different
occurred, I think
Attachment #8823380 - Flags: review?(bugs) → review+
Pushed by michael@thelayzells.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a79d5d23b48f
Rename and simplify the DocShell ProcessLock concept, r=smaug
https://hg.mozilla.org/mozilla-central/rev/a79d5d23b48f
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Comment on attachment 8823380 [details] [diff] [review]
Rename and simplify the DocShell ProcessLock concept

Review of attachment 8823380 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/locales/en-US/chrome/dom/dom.properties
@@ +314,5 @@
>  LargeAllocationSuccess=This page was loaded in a new process due to a Large-Allocation header.
>  # LOCALIZATION NOTE: Do not translate "Large-Allocation", as it is a literal header name. Do not translate GET.
>  LargeAllocationNonGetRequest=A Large-Allocation header was ignored due to the load being triggered by a non-GET request.
> +# LOCALIZATION NOTE: Do not translate "Large-Allocation", as it is a literal header name. Do not translate `window.opener`.
> +LargeAllocationRelatedBrowsingContexts=A Large-Allocation header was ignored due to the presence of windows which have a reference to this browsing context through the frame hierarchy or window.opener.

Please don't change existing strings like this
https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Changing_existing_strings

Will file a follow-up…
Assignee: nobody → michael
Depends on: 1328620
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: