This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--HG--
extra : moz-landing-system : lando
All fronts are destroyed when we call TargetMixin.destroy.
All but the inspector. This changeset move the inspector front destruction
from being done in parallel to panels destruction to do it after.
This highlight races in tests that are not waiting correctly for the full
loading of the grid sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D39408
--HG--
extra : moz-landing-system : lando
InspectorFront.destroy isn't returning a promise. So the `await` in the toolbox
code is not relevant and is only spinning the event loop.
Removing it introduce races which should be fixed.
The toolbox buttons shouldn't try to unhighlight if the inspector isn't used.
Differential Revision: https://phabricator.services.mozilla.com/D39407
--HG--
extra : moz-landing-system : lando
This patch ensures that any existing query text in the search bar is highlighted when the Cmd/Ctrl + F shortcut is used.
Differential Revision: https://phabricator.services.mozilla.com/D38934
--HG--
extra : moz-landing-system : lando
This actor isn't implemented for processes, but only by browsing context targets.
Differential Revision: https://phabricator.services.mozilla.com/D38905
--HG--
extra : moz-landing-system : lando
This has to do with double imprecision. The test originally had toPrecision(6) to
account for this imprecision. It'd round up 499.9999 into 500. When we send
double(500) (which is an epsilon below 500) into ReduceTimePrecision we wind up
coming out with 499.98. By reducing our precision requirement in this test
we can handle that and round 499.98 back up to 500
Differential Revision: https://phabricator.services.mozilla.com/D38809
--HG--
extra : moz-landing-system : lando
WIP for metaclass concept
The best place to start is the test, it outlines what the API looks like.
Differential Revision: https://phabricator.services.mozilla.com/D37253
--HG--
extra : moz-landing-system : lando
Before this patch we would only treat audio elements as replaced if they
had something visible on the page, so if they had the controls attribute.
This is a specific case that we don't really need to worry about. If we
unconditionnally assume audio elements are replaced, then the code is
simpler and the heuristic is still fine for the vast majority of cases.
In fact, it's even more correct, as an audio element that's inline and
does *not* have the controls attribute still has active width/height
properties. So we do need to treat it as replaced even in this case.
Differential Revision: https://phabricator.services.mozilla.com/D39216
--HG--
extra : moz-landing-system : lando
All fronts are destroyed when we call TargetMixin.destroy.
All but the inspector. This changeset move the inspector front destruction
from being done in parallel to panels destruction to do it after.
This highlight races in tests that are not waiting correctly for the full
loading of the grid sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D39408
--HG--
extra : moz-landing-system : lando
InspectorFront.destroy isn't returning a promise. So the `await` in the toolbox
code is not relevant and is only spinning the event loop.
Removing it introduce races which should be fixed.
The toolbox buttons shouldn't try to unhighlight if the inspector isn't used.
Differential Revision: https://phabricator.services.mozilla.com/D39407
--HG--
extra : moz-landing-system : lando
The code callng action.updateRequest, in FirefoxDataProvider, expects the updateRequest action
to be processed once the returned promise is resolved. Otherwise it may spawn
duplicated requestData requests.
Differential Revision: https://phabricator.services.mozilla.com/D39153
--HG--
extra : moz-landing-system : lando
We retrieve the preference in the hudservice, where
WebConsoles and BrowserConsoles are created from.
If the pref is set to true, we assign a different
title to the Browser Console window so it will be
easier to spot.
The preference is then passes to the BrowserConsole,
WebConsole, WebConsoleUI and finally WebConsoleConnectionProxy
instances.
Later, we'll check this pref to connect to different
targets and listen to new ones.
Depends on D39646
Differential Revision: https://phabricator.services.mozilla.com/D39647
--HG--
extra : moz-landing-system : lando
In `EventListeners.css` I added `width: 100%` to the `.event-listener-label` to increase the width of the clickable area.
Differential Revision: https://phabricator.services.mozilla.com/D39500
--HG--
extra : moz-landing-system : lando
The reference isn't used within the component itself,
and is available in the webConsoleUI.
Callsites are updated.
Differential Revision: https://phabricator.services.mozilla.com/D39505
--HG--
extra : moz-landing-system : lando
There's no reason it should be JsTerm's responsability
to clear the output node.
Differential Revision: https://phabricator.services.mozilla.com/D39508
--HG--
extra : moz-landing-system : lando
In the last patch of this series, I forgot to sync `remoteWebNavigationImpl`
state in the progress listener. This patch corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D39395
--HG--
extra : moz-landing-system : lando
Some failures crept in and out after my last sets of annotations landed. This
patch updates most of the annotations to deal with them.
MANUAL PUSH: Lando won't let me land.
Differential Revision: https://phabricator.services.mozilla.com/D39462
--HG--
extra : rebase_source : 4cfccf95c5bb2521533a9f5c4c25d67f414fb6f5
extra : histedit_source : c19187a3b3002e0eebdd809738b57641e1e432cd
The test is supposed that the document is not scalable at all when
"minimum-scale=maximum-scale" is set in the viewport meta content, but it's
actually invalid. A correct content is assumed "minimum-scale=1,maximum-scale=1"
so that the document is not scaled at all.
The reason why this check has passed is that "user-scalable=no" which is set
right before this check remains in cache so that the content of the meta
viewport becomes "user-scalable=no,minimum-scale=maximum-scale" which means the
document is not scalable. But we are going to fix this weird behavior in this
commit series so that we are no longer able to rely on the cached
"user-scalable=no" value.
Differential Revision: https://phabricator.services.mozilla.com/D38919
--HG--
extra : moz-landing-system : lando
The fronts are destroyed when the toolbox closes and when a front is destroyed,
all its listeners are removed. So there is no real value in trying to unregister
them. On top of that, this destroy method is called by Inspector.destroy
and doesn't wait for its completion.
Differential Revision: https://phabricator.services.mozilla.com/D39302
--HG--
extra : moz-landing-system : lando
This code in ToolSidebar.destroy looks dead as there shouldn't be any sidebar
loaded in distinct iframes anymore. So we are not trying to call sidebars destroy
from here anymore. Instead, it is being done from Inspector.destroy, via the _panels
Map.
Differential Revision: https://phabricator.services.mozilla.com/D39301
--HG--
extra : moz-landing-system : lando
Depends on D39335
Looking in details at get(), the implementation can also be simplified
Differential Revision: https://phabricator.services.mozilla.com/D39338
--HG--
rename : devtools/shared/webconsole/parser.js => devtools/shared/webconsole/parser-helper.js
extra : moz-landing-system : lando
We were displaying result.value.throw if result.value.return
was falsy. But it can happen that a getter does return a
falsy value, and we want to display it.
So now we turn the expression the other way around, we first
check result.value.throw, and then default to result.value.return.
A mochitest is added to ensure we hav expected value for different
getters returning falsy values.
Differential Revision: https://phabricator.services.mozilla.com/D39136
--HG--
extra : moz-landing-system : lando
The diagram we had was outdated. We delete
the image, and add 2 ascii diagrams that
reflect the current architecture:
- one for the react part
- one for the non-react part
The style of the page is modified so diagrams can take
the whole horizontal space if needed.
Differential Revision: https://phabricator.services.mozilla.com/D39157
--HG--
extra : moz-landing-system : lando
This avoids intermittent leaks in aboutdebugging tests relying on about:devtools-toolbox
Differential Revision: https://phabricator.services.mozilla.com/D39174
--HG--
extra : moz-landing-system : lando
As part of bug 1510569, the majority of the `nsIWebProgress` event listeners
have moved from the `WebProgressChild`/`RemoteWebProgress` to the
`BrowserChild`/`BrowserParent`. In responsive design mode, the
`RemoteWebProgress` previously would update the state of the `<iframe
mozbrowser>` with document URI and title which would be mirrored back to the
`<xul:browser>` when leaving RDM. However, the event handlers in the
`BrowserParent` call directly into the `<xul:browser>`, skipping the `<iframe
mozbrowser>` entirely. Therefore, when RDM is shut down, old state will be
mirroed to the `<xul:browser>`, leaving it in an inconsistent state. We now
mirror the state from the `<xul:browser>` to the `<iframe mozbrowser>` with an
`nsIWebProgressListener` so that the `<iframe mozbrowser>` will not clobber the
`<xul:browser>`'s state when leaving RDM.
Differential Revision: https://phabricator.services.mozilla.com/D38918
--HG--
extra : moz-landing-system : lando
test_bug819670_getter_throws.html:
Previously, the document context inspected in the console was the test
harness XULDocument, but now it will be an HTMLDocument. Update the
checks to make sure the inspected object has the same own properties as
the test documents own properties.
other tests:
Simply replace the expected document type.
Differential Revision: https://phabricator.services.mozilla.com/D38695
--HG--
extra : moz-landing-system : lando
Depends on D38620
json5 is a much bigger library than JSOL but it doesn't rely on any eval-like code.
It should provide similar features, and testing locally it seems to work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D38515
--HG--
extra : moz-landing-system : lando
Depends on D38619
The new version of JSZip doesn't rely on any eval like code.
Differential Revision: https://phabricator.services.mozilla.com/D38517
--HG--
extra : moz-landing-system : lando
Depends on D38618
The template() helper seems not used in devtools so I removed it here.
If we could generate a bundle of lodash without this method from the start that would be great.
Differential Revision: https://phabricator.services.mozilla.com/D38516
--HG--
extra : moz-landing-system : lando
Depends on D38617
We should no longer use eval-like code in privileged modules
Differential Revision: https://phabricator.services.mozilla.com/D38513
--HG--
extra : moz-landing-system : lando
The template is used in one of the page, but the
plugin wasn't installed, so Gitbook would fail
generating the doc.
Differential Revision: https://phabricator.services.mozilla.com/D39156
--HG--
extra : moz-landing-system : lando
The current auto height and auto width tests were not asserting the proper element.
Differential Revision: https://phabricator.services.mozilla.com/D39102
--HG--
extra : moz-landing-system : lando
Support for coping link location from within the Console panel (through the context menu) can be extended and cover learn more links too.
Differential Revision: https://phabricator.services.mozilla.com/D38546
--HG--
extra : moz-landing-system : lando
**NOTE: This depends on D35513, so if it has not landed yet, please `arc patch D35513` before patching this one on top.**
- `.devtools-button` styles in `common.css` are kinda broken , so I decided to roll out our own button component (`UIButton`) after consulting with Victoria colors, sizes, etc. The other downside to selectors in `common.css` is that they can have a high specificity :(
- Victoria said to use the "micro" style from Photon as the default style for buttons in the panels. So I created an even smaller "micro" styles (very similar to `.devtools-togglebutton`) for when we need smaller buttons.
- I created some light/dark variables in our stylesheets instead of on `variables.css` because `--theme-button-background` was already taken (only used in a single panel, but still…). Maybe after the buttons are fixed globally in the common folder, we could use the variables there. In the meantime, to avoid losing more time, I rolled out our own vars here.
Differential Revision: https://phabricator.services.mozilla.com/D37883
--HG--
extra : moz-landing-system : lando
The patch for Bug 724505 changed the return of `prettifyCSS()` from a string to an object and the reference in the StyleRuleActor.getRuleText() was not updated. This patch fixes this and introduces a test.
Differential Revision: https://phabricator.services.mozilla.com/D38673
--HG--
extra : moz-landing-system : lando
**NOTE: This depends on D35513, so if it has not landed yet, please `arc patch D35513` before patching this one on top.**
- `.devtools-button` styles in `common.css` are kinda broken , so I decided to roll out our own button component (`UIButton`) after consulting with Victoria colors, sizes, etc. The other downside to selectors in `common.css` is that they can have a high specificity :(
- Victoria said to use the "micro" style from Photon as the default style for buttons in the panels. So I created an even smaller "micro" styles (very similar to `.devtools-togglebutton`) for when we need smaller buttons.
- I created some light/dark variables in our stylesheets instead of on `variables.css` because `--theme-button-background` was already taken (only used in a single panel, but still…). Maybe after the buttons are fixed globally in the common folder, we could use the variables there. In the meantime, to avoid losing more time, I rolled out our own vars here.
Differential Revision: https://phabricator.services.mozilla.com/D37883
--HG--
extra : moz-landing-system : lando
When a test crashes, the harness skips all of the remaining tests in the
directory. That means that with crashes skipped, we now try to run a whole lot
more tests than we did before, and a lot of them fail under Fission.
This patch adds annotations to the new failures that show up after part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38726
--HG--
extra : rebase_source : 292157039c88fc615f5de41679e96e72766ac4db
I added `-moz-user-select: none;` to the `.badge` class in devtools/client/accessibility/accessibility.css .
Differential Revision: https://phabricator.services.mozilla.com/D37730
--HG--
extra : moz-landing-system : lando
In `Breakpoint.js` I added an if else statement to the function `addBreakpoint()` to add/remove class "breakpoint-disabled" depending on the value of `breakpoint.disabled`. I then added a selector in `Editor.css` to set `color: blue`.
Differential Revision: https://phabricator.services.mozilla.com/D38017
--HG--
extra : moz-landing-system : lando