Similar to bug 1528654, we currently bail out too early and don't process all of the correct scripts when adding breakpoints.
Differential Revision: https://phabricator.services.mozilla.com/D22355
--HG--
extra : moz-landing-system : lando
We were clearing the ConsoleAPI messages, but not the one
issued by the ConsoleService. A previous patch added
Services.console.resetWindow, so we can use it in `clearMessagesCache`.
Differential Revision: https://phabricator.services.mozilla.com/D21694
--HG--
extra : moz-landing-system : lando
Now that the server is by default loaded in the shared system compartment,
we have to special cases the code debugging system compartments.
When devtools.chrome.enabled is turned on, the event collector is
inspecting the system compartment's event listener.
In this case, we are using a special Debugger instance loaded in
a sandbox flagged with invisibleToDebugger=true. This forces loading it
in a distinct compartment and helps the debugger know about the boundaries
between debugger and debuggee code.
It should be safe to only load the Debugger and not the whole server here
as event collector is only inspecting and doesn't register any callback on
the Debugger API.
Differential Revision: https://phabricator.services.mozilla.com/D22070
--HG--
extra : moz-landing-system : lando
When reviewing https://bugzilla.mozilla.org/show_bug.cgi?id=1521052 I did not think about Firefox for Android which is not using e10s.
This means the main DebuggerServer will be killed when there are no connections left. Happy to discuss more about the preferred solution.
This is a regression in 66 and I hope to uplift a fix for this.
Differential Revision: https://phabricator.services.mozilla.com/D20830
--HG--
extra : moz-landing-system : lando
When reviewing https://bugzilla.mozilla.org/show_bug.cgi?id=1521052 I did not think about Firefox for Android which is not using e10s.
This means the main DebuggerServer will be killed when there are no connections left. Happy to discuss more about the preferred solution.
This is a regression in 66 and I hope to uplift a fix for this.
Differential Revision: https://phabricator.services.mozilla.com/D20830
--HG--
extra : moz-landing-system : lando
This patch adds a boolean option to skip the cached value of `StyeRuleActor.authoredText` and re-parse the stylesheet for its value.
When changing content of a descendant rule inside an ancestor like @media or @select, the cached `authoredText` value is outdated.
This yields incorrect data when requesting the complete rule authored text, hence the need for a cache-busting option.
In addition to this change, there is a slight refactor to include the generated unique selector for the mock-rule for element inline styles.
Differential Revision: https://phabricator.services.mozilla.com/D21033
--HG--
extra : moz-landing-system : lando
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
Dorel Luca
Jason Laster
ravefalcon92
Nicolas Chevobbe
shindli
Alexandre Poirot
Felipe Gomes
yulia
Brian Hackett
Daisuke Akatsuka
Cosmin Sabou
Razvan Maries
Daniel Varga
Logan Smyth
Jonathan Kingston
Julian Descottes
Razvan Caliman
Andreea Pavel
Brindusan Cristian
Boris Zbarsky
Coroiu Cristina
Michael Ratcliffe