Surprisingly, previous changeset fix this. Following changeset is rather there for cleanups.
The fact that we instantiate a first JSWindowActor pair from frame-helper seems to do the trick.
The new code in frame-helper no longer conditionaly create the target for the top BC.
I also silent an exception happening in this test without fission.
Differential Revision: https://phabricator.services.mozilla.com/D117472
This only failed with devtools.target-switching.server.enabled=true as we emit top level target
from the Watcher only when this is enabled.
This is covered by browser_target_list_frames.js asserting a precise order in targets.
This test was failing with the pref set to true and should now pass in all 4 configurations.
(fission on/off + server target on/off)
Also try to destroy the top level target last, after all the remote iframes ones, but I'm not sure it is as important.
Note that we were trying to add the top level BC multiple times between code in utils.js vs worker-helper and frame-helper:getWatchingBrowsingContexts.
Differential Revision: https://phabricator.services.mozilla.com/D117471
This slightly changes panel initialization,
instead of updating the UI on opening as soon as the first top level target is available,
it will only update once the navigate resource fires.
So if we open the toolbox on a still loading document, it will update later, but only once
instead of twice.
Differential Revision: https://phabricator.services.mozilla.com/D117515
I'm not sure it is useful to hide ResourceCommand in the proxy layer.
It is better if all frontend uses Commands directly, having intermediate layer
make it harder to understand and debug.
Differential Revision: https://phabricator.services.mozilla.com/D117513
This help also remove the target watching as this was there
only to workaround the complexity/limitations of target actor's will-navigate.
`waitForSourceLoad` was resolving immediately on previous source,
already available before the reload.
Differential Revision: https://phabricator.services.mozilla.com/D117475
This is slightly complicated by the fact that the editor code wants to be able
to set this from the content process, so we really need separate
BrowsingContext and WindowContext flags, the latter of which can be set by the
owning process.
Differential Revision: https://phabricator.services.mozilla.com/D114899
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
The method was only used in one test, that was disabled
most of the time (only running on non-debug non-e10s).
It seems safe to remove it since we have a mochitest
that is checking ua stylesheets (browser_rules_user-agent-styles.js).
Differential Revision: https://phabricator.services.mozilla.com/D117438
The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116481
This test is not relevant in fission as we aren't using listStores,
nor do we have any EXTENSION_STORAGE resource to test yet.
Differential Revision: https://phabricator.services.mozilla.com/D116483
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116482
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116480
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116479
This is important to emit `connectFromContent` before processing the watched data.
We have to notify the parent process (and the client) about the new target actor.
And do that before any code in the content process tries to emit an event via this target acotr.
We will typically start the resources watchers when processing the watched data,
which will emit the resources-available-form on the target actor.
Writing a test for this is a bit tricky, as we start missing event when we get into it.
browser_resources_document_events.js starts failing without this patch because DOCUMENT_EVENT's dom-loading is emitted immediately
and is lost in the parent process.
I'm not sure we can write a better test than this existing failure.
Differential Revision: https://phabricator.services.mozilla.com/D117149
These events are redundant with target creation and destruction when the targets
follows the window lifecycle. These events are now only useful for in-process iframes.
Also, when the Target is instantiated by the server codebase, we end up registering
the code emitting these events sooner, so that we emit window-ready for the existing document!
On top of that, we end up also instantiating (and attaching) the thread actor earlier.
When combined, the thread actor was receiving window-ready for the existing top document
and was reseting itself after being attached and having registered the breakpoints.
Some followup would be required for will-navigate.
We get an initial will-navigate when the target instantiate, which can also confuse actors.
But as this event is important for DocumentEventWatcher, more work is needed to disable it.
Differential Revision: https://phabricator.services.mozilla.com/D117148
I thought I would reused browser_dbg-navigation.js, but its doc-scripts.html
test page is too complex and doesn't reproduce the broken breakpoint.
So I'm still cleaning it up, but ended up introducing a new dedicated test and test page.
Note that I'm removing the toggleScopes call as it was most likely a workaround.
Test helpers assume that scopes are visible and timeout if the scopes don't get updated.
The added test now only fails without fission + with server target switching.
Differential Revision: https://phabricator.services.mozilla.com/D116811
This results in lots of new WPT test passes.
There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.
Depends on D117331
Differential Revision: https://phabricator.services.mozilla.com/D117332
The test opens the inspector and retrieves the testActor,
then a navigation occurs and testActor is used to check
if the highlighter works.
When server-side target switching is enabled, the testActor
gets destroyed during the navigation, and when it throws
when we try to use it in the new document.
To fix this, we only retrieve the testActor once we navigated.
Differential Revision: https://phabricator.services.mozilla.com/D117267
These methods are replaced by a helper in shared-head that
sets the fullZoom property on the browsing context.
A new testActor method, waitForHighlighterUpdate, is added
so we can know when a given highlighter is updated (which
is something that was done in changeZoomLevel).
Differential Revision: https://phabricator.services.mozilla.com/D117263
Now we have d property, so the list of auto completion should include d
property when typing 'd'. We need to add more tabs or up/down keys to
choose the keyword we want.
Differential Revision: https://phabricator.services.mozilla.com/D115752
Mike Kaply
Alexandre Poirot
Yaron Tausky
Kris Maglione
Emilio Cobos Álvarez
Andrew Halberstadt
Jonathan Kew
Hubert Boma Manilla
Silke Hofmann
Dana Keeler
Butkovits Atila
Nicolas Chevobbe
Julian Descottes
Iulian Moraru
Olli Pettay
Andrey Bienkowski
Peter Van der Beken
Boris Chiou