When removing all declarations from a rule via the Rule view, the authoredText value ends up as an empty string.
This patch ensures that the fallback cssText is not used in that case because that accidentally restores the whole declaration block when re-parsing the text of the rule.
Differential Revision: https://phabricator.services.mozilla.com/D14753
--HG--
extra : moz-landing-system : lando
The basic idea is to make non-initial about:blank fire
document-element-inserted notifications just like every other document. We
then ensure that there's a notification (initial-document-element-inserted)
that only gets fired once per window for documents that are in a window. This
notification is what webextensions use to inject into the document.
The old setup which injected into about:blank when its global is created gets
removed in favor of injecting the same way as into every other document.
The changes to Document.cpp are fixing a bug in the "block the parser" stuff
webextensions do. For about:blank, the blocking happens at a point when the
parser really has nothing else to parse (since it's parsing the empty string).
So the blocking is a no-op. But we do want to prevent DOMContentLoaded firing,
because otherwise the "end of document" scripts could run before we finish
doing the "beginning of document" work in webextensions. So we want to make
sure we block DOMContentLoaded, not just the load event.
Differential Revision: https://phabricator.services.mozilla.com/D19892
--HG--
extra : moz-landing-system : lando
A JSScript can be explicitly cloned and applied to a new realm. When this is done within the same compartment
as the original JSScript, it maintains its reference to the original ScriptSourceObject. This can lead to the
potentially surprising fact that using Debugger.findScripts({ source }) can return multiple Debugger.Script
objects representing the same function, but in multiple realms.
When we query for breakpoints in a given source, we want to take the first column breakpoint on a given line,
but that needs to apply to all potential instances of the Debugger.Script for that location, not just the first one.
Differential Revision: https://phabricator.services.mozilla.com/D20431
--HG--
extra : moz-landing-system : lando
It's possible that CSSPseudoElement will grow a 'ownerDocument' member in future
so instead we should test for '.element'. We could also test for '.type' but it
seems more likely that Element will grow a 'type' member than an 'element'
member.
Ideally we should really test if the target is an instanceof CSSPseudoElement
but unfortunately the window() getter it itself defined in terms of the node()
getter (which calls isPseudoElement) so we'd end up with unbounded recursion
unless we restructure these getters.
Differential Revision: https://phabricator.services.mozilla.com/D20428
--HG--
extra : moz-landing-system : lando
Depends on D20195
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
- adds method to identify a CSS Rule actor by id
- adds context menu option to the Changes panel to allow copying the rule's authored text to the clipboard
Differential Revision: https://phabricator.services.mozilla.com/D20196
--HG--
extra : moz-landing-system : lando
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
This patch adds a new method to the StyleRuleActor on the server to expose the full text content of a CSS rule over the protocol to the client. This means exposing the CSS rule's authored text including comments and any nested rules if the target rule is an ancestor rule, like @media or @supports.
There's minor refactoring to include additional rule types for which StyleRuleActors will be created: @supports, @media, @keyframes. These are not explicitly rendered in the Rule view and shouldn't impact it. The Rule view filters for CSS Style Rules, element inline style and has special handling for keyframe at-rules.
Differential Revision: https://phabricator.services.mozilla.com/D20195
--HG--
extra : moz-landing-system : lando
this patch introduces events for the webconsoleFront -- not all of them are being listened
to by their subscribers yet, but this is the bulk of the effort to move events to Protocol.js
Differential Revision: https://phabricator.services.mozilla.com/D18832
--HG--
extra : moz-landing-system : lando
Refactors the Redux state for the Changes panel so that rules have
a `selectors` array instead of just a single `selector` string.
The `selectors` array represents the **history** of selector text the
rule has over time, not the actual list of multiple selectors it has
(multiple selectors are collapsed into a single comma-separated string
regardless of how many they are).
When the server logs changes, the rule's selector text is checked
against the history of previously logged selectors.
If the incoming selector is different than the _first_ item in
the tracked rule's `selectors` array, it means the selector was renamed
so it is pushed onto the array (added to the history).
If it's the same, the whole array can be reduced to the original value
because it means that either:
- the selector didn't change between operations (ex: after declaration changes)
- the selector reverted back to its original name.
This `selectors` array is used in the React component in Part 2 of this
series to render any necessary diff view of the selector.
The old approach (whole rule removal + whole rule addition) is replaced
by this refactor. The introduction of the StyleRyleActor actor id from
the server as the rule id on the client in Bug 1525238 means that the
selector change can no longer behave like two distinct rules.
The actorID/rule id are preserved after selector renames. This necessary
for the some export options to work consistently (like Copy Rule with changes applied).
Differential Revision: https://phabricator.services.mozilla.com/D19828
--HG--
extra : moz-landing-system : lando
Replaces custom generated hashes with the actorIDs which are stable
during the editing session enough to use as unique identifiers.
For future restore / persistence, we still have the metadata about each
rule and stylesheet to attempt to identify them again.
Differential Revision: https://phabricator.services.mozilla.com/D18660
--HG--
extra : moz-landing-system : lando
The reason why we use RelaxedAtomBoolis that
ScrollSnapUtils::GetSnapPointForDestination() is called both from the main and
the compositor threads, and the function will have a branch depending on the
pref value.
Differential Revision: https://phabricator.services.mozilla.com/D20101
--HG--
extra : moz-landing-system : lando
The basic idea is to make non-initial about:blank fire
document-element-inserted notifications just like every other document. We
then ensure that there's a notification (initial-document-element-inserted)
that only gets fired once per window for documents that are in a window. This
notification is what webextensions use to inject into the document.
The old setup which injected into about:blank when its global is created gets
removed in favor of injecting the same way as into every other document.
The changes to Document.cpp are fixing a bug in the "block the parser" stuff
webextensions do. For about:blank, the blocking happens at a point when the
parser really has nothing else to parse (since it's parsing the empty string).
So the blocking is a no-op. But we do want to prevent DOMContentLoaded firing,
because otherwise the "end of document" scripts could run before we finish
doing the "beginning of document" work in webextensions. So we want to make
sure we block DOMContentLoaded, not just the load event.
Differential Revision: https://phabricator.services.mozilla.com/D19892
--HG--
extra : moz-landing-system : lando
Any time we QI to nsIFrameLoaderOwner in tests, we're really accessing
a MozFrameLoader. We don't need to be doing that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19727
--HG--
extra : moz-landing-system : lando
There are 2 changes in this patch.
In js-property-provider, we iterate over a Set
and delete item we don't want into instead of
turning the Set into an array, filter on it, and
convert it back to a new Set.
In the autocomplete function, we don't use regexp
anymore in the sort callback as we already have
a way to tell if we're performing an element access.
Differential Revision: https://phabricator.services.mozilla.com/D19471
--HG--
extra : moz-landing-system : lando
Now that the base Target class is managing the thread client,
we no longer have to send "newSource" on the target actor, and instead,
listen for newSource directly on the thread client.
We should probably align updatedSource and have this event being emitted on
the thread actor as well.
Depends on D18813
Differential Revision: https://phabricator.services.mozilla.com/D18814
--HG--
extra : moz-landing-system : lando
There is still some tight connection between ThreadClient and Target,
- Target.threadClient, which should ideally disappear in favor of
target.getFront("thread")
- Target.threadClient is manually nullified from ThreadClient.detach,
but that should disappear as well thanks to getFront.
Differential Revision: https://phabricator.services.mozilla.com/D18813
--HG--
extra : moz-landing-system : lando
This will be used in telemetry events. Also,
we add `errorMessageName` in evaluation result packets.
Stubs are generated so they include the new property.
Differential Revision: https://phabricator.services.mozilla.com/D18925
--HG--
extra : moz-landing-system : lando
Evaluation of debuggee code should always begin with an empty microtask queue.
In xpcshell tests, this is not guaranteed, as it is in the web platform. This
patch changes those devtools server xpcshell tests that break this rule in a
detectable way to run the debuggee code as a separate HTML task.
In an actual browser environment, debuggee JavaScript runs as an HTML task.
Since HTML requires a microtask checkpoint at the end of each task, this means
that a debuggee task begins execution with an empty microtask queue, free of
microtasks from other tabs or the browser machinery itself. Hence, while the
debugger is pausing debuggee code, it is safe for it to save the debuggee's
microtask queue, so that those jobs do not make progress. (Which is fortunate,
because it *must* do so, lest the debuggee's microtasks run during the pause!)
In an xpcshell test, however, there is no guarantee that debuggee code begins
execution with a fresh microtask queue: the test may call `eval` or
`evalInSandbox` at any time. If such an evaluation hits a breakpoint, `debugger`
statement, etc. that invokes a Debugger hook, supervisory microtasks from the
test harness code may be set aside along with the debuggee's microtasks. If the
hook code then blocks waiting for those microtasks to run, the test will hang.
Differential Revision: https://phabricator.services.mozilla.com/D18904
--HG--
extra : moz-landing-system : lando
Making use of the new SpiderMonkey APIs for available breakpoints means
that the server needs to think a lot less about where it is pausing and
allows us to drop the concept of a pause points from the server entirely.
It is now up to SpiderMonkey to decide where it will and will not stop
when it is stepping.
Differential Revision: https://phabricator.services.mozilla.com/D17665
--HG--
extra : moz-landing-system : lando
The step-out logic currently has a special case to skip pausing onPop
when stepping out of the current frame. This logic gets confused if
you are already _in_ the onPop of the current frame though, and
causes you to also fail to pause onPop in the parent frame.
Differential Revision: https://phabricator.services.mozilla.com/D17663
--HG--
extra : moz-landing-system : lando
This brings SpiderMonkey more in line with V8 for the positions that it uses for expressions
nested within statements. We generally prefer to use the expression's own location
rather than the location of the statement, in the majority of cases.
Differential Revision: https://phabricator.services.mozilla.com/D15993
--HG--
extra : moz-landing-system : lando
Depends on D19159
This will fix the test browser_aboutdebugging_serviceworker_status.js when running with dom.serviceWorkers.parent_intercept=true
(`./mach test browser_aboutdebugging_serviceworker_status.js --setpref dom.serviceWorkers.parent_intercept=true`)
Differential Revision: https://phabricator.services.mozilla.com/D18365
--HG--
extra : moz-landing-system : lando