Before Quantum, we needed resizer icon on Windows, because when the
add-on statusbar was hidden, we could not resize the window. This is not
needed anymore and is dead code. Consequentially, this also helps reduce
unused images loaded at startup time.
Differential Revision: https://phabricator.services.mozilla.com/D91196
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
Creating more than 2 nested iframes is not allowed and is now enforced for
about:blank loads because they now take place via DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D85084
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Creating more than 2 nested iframes is not allowed and is now enforced for
about:blank loads because they now take place via DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D85084
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
nsMIMEInputStream was conditionally serializable depending on the
wrapped stream. In general when a stream needs to be sent over IPC, if
it isn't serializable we send it using
InputStreamHelper::SerializeInputStreamAsPipe. There is no reason to
not branch on the wrapped stream when serializing nsMIMEInputStream
and use that, instead of sending the nsMIMEInputStream itself over a
pipe.
Differential Revision: https://phabricator.services.mozilla.com/D80890
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
The first page's content viewer is only saved in the bfcache when the second
page is painted. This can happen after the load event is fired, and in that
scenario, attempting to go back to the first page will reload it rather than
restore it from the bfcache. So for the test to work properly it needs to
wait until the second page is actually painted before it attempts go back.
Differential Revision: https://phabricator.services.mozilla.com/D79347
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
With recent fixes that can properly identify whitelisted domains, whitelisted
domain suffixed, valid known public suffixes, and forcing to visit URI-like
strings that end with a slash, it's time to re-evaluate the URIFixup behavior.
Until now URIFixup considered everything a URI unless it had specific search
characteristics, this patch inverts that behavior.
The scope of this change is to improve the urlbar behavior as the main Search
Access Point, since that's the direction we're moving towards.
This lands with a temporary hidden feature pref browser.fixup.defaultToSearch,
that will be removed once the feature has been released.
Differential Revision: https://phabricator.services.mozilla.com/D76852
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This is mostly changes to handle retrieving the security state asynchronously via the parent process, needing lots of async/await additions.
It also removes the docshell mixed content flag checks (which don't seem to be used in code, only tests), which are mostly still covered by checks of the security UI.
Differential Revision: https://phabricator.services.mozilla.com/D75448
This changes the urlbar to always generate a result and then confirm it through
pickResult. This way we obtain a consistent behavior independently from whether
the view has a result or an action like Paste&Go happened.
Before this we used to go through getShortcutOrURIAndPostData, that implements
only a part of the urlbar logic, often causing different behavior depending on
the view state, and thus requiring constant maintenance to sync it up.
In a follow-up bug we will evaluate the complete removal of
getShortcutOrURIAndPostData in favor of direct calls to
UrlbarUtils.getHeuristicResultFor().
This also moves up a bit closer to always pass a final url to the docshell, and
stop trying to do complex URIFixup calls in it. For now we still rely
on its fix-ups for browser.fixup.dns_first_for_single_words, where we pass a
url, and if it's invalid it will instead search. See UrlbarUtils.RESULT_TYPE.URL
handling in pickResult().
Differential Revision: https://phabricator.services.mozilla.com/D75911
This changes the urlbar to always generate a result and then confirm it through
pickResult. This way we obtain a consistent behavior independently from whether
the view has a result or an action like Paste&Go happened.
Before this we used to go through getShortcutOrURIAndPostData, that implements
only a part of the urlbar logic, often causing different behavior depending on
the view state, and thus requiring constant maintenance to sync it up.
In a follow-up bug we will evaluate the complete removal of
getShortcutOrURIAndPostData in favor of direct calls to
UrlbarUtils.getHeuristicResultFor().
This also moves up a bit closer to always pass a final url to the docshell, and
stop trying to do complex URIFixup calls in it. For now we still rely
on its fix-ups for browser.fixup.dns_first_for_single_words, where we pass a
url, and if it's invalid it will instead search. See UrlbarUtils.RESULT_TYPE.URL
handling in pickResult().
Differential Revision: https://phabricator.services.mozilla.com/D75911
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
Things that were broken:
- prompts become unreadable when using dark-background lwthemes, because they
keep the window text-shadow (due to the namespace change of tabmodalprompt)
- prompts with long text without word-wrap possibilities
(e.g. `alert("x".repeat(1000))`) cause the text to escape its container.
Differential Revision: https://phabricator.services.mozilla.com/D73131
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair. The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
Use the PSL list to evaluate whether user typed strings in urlbar are valid URLs.
Cleanup the URIFixupInfo.fixupChangedProtocol property to be set appropriately.
Auto-correct the most common suffix typos for com, net, org.
Stop using URIFixup to trim urls when the urlbar value is set, instead always trim,
then untrim on focus if the trimmed string would cause, on navigation, a search
instead of a visit. This saves us from doing the URIfixup work on page load and
tab switch, running it only when strictly necessary.
Fix the "Did you mean to go to" prompt to show a protocol, avoiding the
confusing (but funny) "did you mean to go to 'space'" prompts.
Differential Revision: https://phabricator.services.mozilla.com/D68796
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
--HG--
extra : moz-landing-system : lando
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
I think I caught all the places in our tree that add event listeners for these
events on a non-Window (and hence depend on bubbling behavior), but I'm a
little worried about what happens if webextensions do bareword
addEventListener() for these events...
Differential Revision: https://phabricator.services.mozilla.com/D66798
--HG--
extra : moz-landing-system : lando
The patch ensures we don't pass a nsIWebNavigation load flag to
nsIDocShell.defaultLoadFlags which is supposed to get nsLoadFlags (nsIRequest).
Differential Revision: https://phabricator.services.mozilla.com/D61168
--HG--
extra : moz-landing-system : lando
I tested this by using delay(1) instead of delay(100), which reliably gives me
the "Is on an error page initially" failure without these changes and reliably
passs with them.
Differential Revision: https://phabricator.services.mozilla.com//D60345
--HG--
extra : histedit_source : e1c31b6183b569d7474af0de09292cc51635af5d
Some notes about the changes:
Both test_bug384014.html and test_bug123696.html were testing reloading of
javascript: URI. The expected result of the iframes after reloading would
become about:blank. I deleted both file and instead wrote with
web-platform-test to cover reloading of javascript: URI since wpt is more
preferable.
storage-cache-error.html was utilizing javascript: URI to test bug 1262766.
javascript: URI would cause CacheStorage::Keys to throw a dom security
exception because the URI's principal (which did not match the principal of the
document in this case!) was a nullpricipal. With my patches the iframe's URL
would no longer be the javascript: URI, so it's no longer applicable for the
test case. Instead we can test what bug 1262766 was originally about - that
CacheStorage::Keys would throw a dom security exception if it's in a private
browsing window.
Differential Revision: https://phabricator.services.mozilla.com/D59465
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.
When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.
This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).
Differential Revision: https://phabricator.services.mozilla.com/D55222
--HG--
extra : moz-landing-system : lando
This ensures that we wait for the desired URL in the browserLoaded call, rather
than resolving the first-loaded one.
This also renames the file to make it more indicative of what it actually tests.
Differential Revision: https://phabricator.services.mozilla.com/D55045
--HG--
extra : moz-landing-system : lando
This is a partial fix, which prevents the test from simply timing out. It
still fails, because this is a test of content session history listeners,
which don't currently work as expected for cross-process navigations.
Differential Revision: https://phabricator.services.mozilla.com/D51696
--HG--
rename : docshell/test/browser/file_bug422543_script.js => docshell/test/browser/Bug422543Child.jsm
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
I rewrote BrowserUtils.addContentEventListener(), and that caused an
intermittent failure in browser_bug343515.js. The use of
addContentEventListener in the test is questionable, and the test as a
whole is old, so I freshened it up.
Instead of nShotsListener (and oneShotListener, which is a special
case of that) which waits for a hard coded number of load events to
fire to ensure that a page and its subframes are all loaded, I use
BrowserTestUtils.browserLoaded().
Instead of waitForPageshow, which runs a script in the content process
that waits for an event, it uses BrowserTestUtils.waitForContentEvent,
which does the same thing in a hopefully more resilient fashion.
The largest change in terms of number of characters changed is that I
rewrote the test so that it is written inside of a single add_task
async function, instead of being split into a chain of async
functions. I also used await to flatten a lot of .then() chained
things.
I fixed up some variable shadowing. There was some trickiness around
shadowed variable names being used as field names, so I introduced an
intermediate 'data' variable to hold the structure.
Finally, I call BrowserTestUtils.removeTab() instead of calling
removeTab() directly on the browser. I figured that was probably
better, though maybe it does not matter.
I added a check after each step that the URI is correct, where
missing, which would have caught a bug in an earlier version of this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D51183
--HG--
extra : moz-landing-system : lando
The changes try to ensure we haven't really started load process of the new page, just that
there is ongoing active request. history.back() will then only affect to the fragment navigation.
Differential Revision: https://phabricator.services.mozilla.com/D50220
--HG--
rename : docshell/test/navigation/file_fragment_handling_during_load_frame2.html => docshell/test/navigation/file_fragment_handling_during_load_frame2.sjs
extra : moz-landing-system : lando
All but browser_bug744745.js seem to pass even without the fixes I
made, which seems odd.
browser_bug1058164.js is a little odd because it passes in {} instead
of a boolean for the useCapture argument. I think this ends up calling
addEventListener(..., {}, false), which should be the equivalent of
addEventListener(..., {}).
Differential Revision: https://phabricator.services.mozilla.com/D49453
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
We attempt to enforce the same (approximate) access checks to Location-based
navigation that we use for loads that use named targeting (e.g., via
window.open), so that a frame that can't be navigated via, e.g., window.open,
also can't be navigated via, e.g., window.parent[1].location = url. For the
in-process case, this is handled by a somewhat hidden call to
CheckLoadingPermissions() in nsDocShell::InternalLoad, where the former checks
whether the principal of whatever JS context happens to be on the stack
subsumes the principal of the target DocShell or any of its ancestors, and
blocks the load if it doesn't.
Since there is no JS context on the stack when we call into the DocShell
loading code in the cross-process case, the check is simply ignored.
So we need to instead do the check in BrowsingContext::LoadURI, where we
already have an explicit accessor, and can simply use the standard access
checks that we use elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D48443
--HG--
extra : moz-landing-system : lando
These still fail or timeout because of missing platform features, but at least
the tests will pass once those platform features are fixed after this.
Differential Revision: https://phabricator.services.mozilla.com/D48221
--HG--
extra : moz-landing-system : lando
The key change here is to use SpecialPowers.spawn to access `location.href`
and `location.reload()` for remote windows in the correct proceses. The
remaining changes are refactorings to make it easier to encorporate async
operations like `SpecialPowers.spawn` in the test logic.
Differential Revision: https://phabricator.services.mozilla.com/D48220
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
BrowsingContext.findWithName is required to do access checks based on the
requestor, which can only be done in the process which owns it. This change
also alters the behavior of the existing CanAccess origin checks, which
typically treat any item as same-origin, but only when the docshells are
actually same process.
Removing the exemption fixes the behavior discrepancy between Fission and
non-Fission runs, but also requires that the test be updated to expect proper
access checks. Which is the situation we really want to test, anyway.
Differential Revision: https://phabricator.services.mozilla.com/D45837
--HG--
extra : moz-landing-system : lando
In the Quantum Bar it's usually the urlbar code that decides whether a search
string should be visited or searched. if dns_first_for_single_words is set,
we can't make a final decision, because that depends on a dns lookup. For now
we don't want to duplicate the docshell code, also because we must keep the
old behavior functioning for cases where the urlbar value is set without input.
Similarly, when the docshell decides to search for a single word host, and a
dns lookup resolves it, it also shows a prompt asking the user if he meant to
visit it instead of searching. Because the urlbar skips the docshell decision
making, we must manually call the fixup prompt code from the urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D45743
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
Olli Pettay
Andreas Farre
Anny G
Peter Van der Beken
Kris Maglione
pbz
Anny Gakhokidze
Mark Banner
Edgar Chen
Csoregi Natalia
Butkovits Atila
Sebastian Streich
Kashav Madan
Noemi Erli
Jonathan Almeida [:jonalmeida]
Dorel Luca
prathiksha
Razvan Maries
Marco Bonardo
tkhan
Bogdan Tara
Coroiu Cristina
Gabriel Luong
Christoph Kerschbaumer
Matt Woodrow
Dave Townsend
Logan Smyth
Kartikaya Gupta
Johann Hofmann
Masatoshi Kimura
Sid Stamm
Tim Huang
Dan Glastonbury
Ian Moody
Gijs Kruitbosch
Jean-Yves Avenard
Tim Nguyen
Andreea Pavel
Stefan Hindli
Mike Hommey
Nika Layzell
Brian Grinstead
Cosmin Sabou
Neil Deakin
Ed Lee
Boris Zbarsky
Arthur Iakab
egao
Valentin Gosu
Samael Wang
Emma Malysz
Henri Sivonen
Oana Pop Rus
Daniel Varga
Geoff Brown
Ehsan Akhgari
Ciure Andrei
Sebastian Hengst
Brendan Dahl
Mihai Alexandru Michis
Andrew McCreight
Narcis Beleuzu
Dylan Roeh
Brindusan Cristian
Emilio Cobos Álvarez