`hasAttribute` and `getAttribute` were using for..of loop to
get what they wanted, which wasn't ideal.
Moreover, most of those operations were happening because we
didn't pass the attribute value to the parseAttribute function,
only an array of all the attributes. This is a bit unfortunate
there's only one place where we call the parseAttribute function,
and there, we have easy access to the attribute value.
This patch removes direct calls to hasAttribute and getAttribute.
hasAttribute is removed, but we need to keep getAttribute for the
isValid function in parsers.
We add an `attributeValue` parameter to the parseAttribute function.
The unit test for this function is also modified to pass the attribute
value.
perfherder reports a ~2.5% improvement on custom open and ~3% on
custom reload.
Differential Revision: https://phabricator.services.mozilla.com/D37551
--HG--
extra : moz-landing-system : lando
Since Firefox 67 tracked changes have unique identifiers as follows:
- ruleId => StyleRuleActor.actorID
- sourceId => StylesheetActor.actorID
Given that we're at Firefox 70 and beyond the window where we support connecting to servers older than 3 versions, this patch removes the backwards compatibility provided by methods to generate unique ids based on attributes of the rule and stylesheet for the tracked change.
Differential Revision: https://phabricator.services.mozilla.com/D37591
--HG--
extra : moz-landing-system : lando
We weren't handling comments at all, which means that having
any in the console would probably make the autocomplete not
working.
This patch handles both inline and multiline javascript comments,
and adds test cases to ensure we don't regress.
Depends on D36573
Differential Revision: https://phabricator.services.mozilla.com/D37196
--HG--
extra : moz-landing-system : lando
We'd like to enable the Origin header for all eligible reqeusts, which include POST.
The test should be adjusted.
Differential Revision: https://phabricator.services.mozilla.com/D33382
--HG--
extra : moz-landing-system : lando
We'd like to enable the Origin header for all eligible reqeusts, which include POST.
The test should be adjusted.
Differential Revision: https://phabricator.services.mozilla.com/D33382
--HG--
extra : moz-landing-system : lando
We use the openNetworkDetails prop which is already in use
in the netmonitor to collapse the message if the parameter
passed to the function is falsy (i.e. the panel is already
displayed)
Depends on D37388
Differential Revision: https://phabricator.services.mozilla.com/D37389
--HG--
extra : moz-landing-system : lando
This prop is only used when hideToggleButton isn't truthy.
In the case of the console, it won't ever be called, so
it's not mandatory.
Differential Revision: https://phabricator.services.mozilla.com/D37388
--HG--
extra : moz-landing-system : lando
Some people found that the ConfirmDialog was getting into their
way when typing into the console, as it was stealing the focus.
This patch fixes this by not focusing the ConfirmDialog when
we show it, so the user can still type.
This means that we now handle the dialog confirm and dismiss from
JSTerm, when the former is displayed.
Since it wasn't clear how you could close the popup, we add a close
button that makes it very obvious.
This means we can drop the key handler in the dialog as the jsterm
is always focused.
We also simply remove the feature to open the MDN link on `?` key
stroke as it's not discoverable and was the only part of the
panel where you could do such thing.
Existing tests are adapted and extended to cover the new behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D36174
--HG--
extra : moz-landing-system : lando
Remove devtools.netmonitor.features.resizeColumns pref and any reference to it.
Differential Revision: https://phabricator.services.mozilla.com/D37159
--HG--
extra : moz-landing-system : lando
The console fails to connect to the server because
the getCachedMessages function throws on GMail.
This is because we try to access a property on a
cross-origin object, window.windowUtils, in
getInnerWindowId.
Wrapping the access to the property fixes the issue.
A test is added to make sure we don't regress.
// TODO: The test isn't failing without the fix,
so it should be re-written.
Differential Revision: https://phabricator.services.mozilla.com/D37069
--HG--
extra : moz-landing-system : lando
We were using Array.from to get an array of all the characters, and
be able to slice parts of the strings to run some checks.
This had the disadvantage of being quite slow on very large strings,
at a point where we introduced a bail out mechanism into the function
to not block the content page.
This patch switches to `String.prototype[Symbol.iterator]` to loop
over all the character, and removes lots of array and string manipulations.
On the same, super-large, string, the function cost went from 6700ms to
less than 200ms.
Differential Revision: https://phabricator.services.mozilla.com/D36572
--HG--
extra : moz-landing-system : lando
Already tested via toolbox menus in devtools/client/framework/test/browser_toolbox_zoom_popup.js
Could open a follow up to allow for other anchor points than bottom-left.
Differential Revision: https://phabricator.services.mozilla.com/D37044
--HG--
extra : moz-landing-system : lando
We were clearing the completion text all the time to prevent
a visual glitch while typing (See Bug 1491776). But since we
are now waiting for 75ms before calling the autocomplete
function (which triggers the autocompletion text update), we
have a flash of the completion text, which isn't ideal.
In this patch, we check if the typed letters match the begining
of the completion text, and if they do, we don't clear the
completion text.
In the same time, we set the completion text in absolute position
so it doesn't jump when the new letter is added in the CodeMirror
document.
Finally, we change how the Editor pipe events from CodeMirror to
include parameters, so we can use them in JsTerm.
Differential Revision: https://phabricator.services.mozilla.com/D36163
--HG--
extra : moz-landing-system : lando
Also changed the border radius to be consistent between doorhanger and arrow style tooltips.
There are still subtle differences between the XUL+arrow/HTML+arrow/XUL+doorhanger, but for now I would just like to fix this before we merge to 70.
Strictly using the photon shadow for doorhangers is too subtle and too inconsistent with our other tooltips, so I used shadow-20.
Differential Revision: https://phabricator.services.mozilla.com/D36767
--HG--
extra : moz-landing-system : lando
