CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
The UA input field gets caught off when the browser viewport is too small. This is because the RDM toolbar has an explicit height of 30px set on it, so it can't accomodate the second row created for the UA input.
Differential Revision: https://phabricator.services.mozilla.com/D56783
--HG--
extra : moz-landing-system : lando
Depends on D55829
In case other rejects are still using strings instead of error objects.
Differential Revision: https://phabricator.services.mozilla.com/D55830
--HG--
extra : moz-landing-system : lando
I refactored some of the unit tests to see if I'm on the right direction. If so, I'll continue with other unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D55923
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This revision modifies RDM UI’s `getViewportBrowser` to return the tab’s <browser> instead of the <mozbrowser> this.toolWindow’s [getViewportBrowser method](https://searchfox.org/mozilla-central/source/devtools/client/responsive/index.js#176) returns. If the pref `devtools.responsive.browserUI.enabled` is set to true, this will cause this.toolWindow to be null because this object is set during the [swap step when RDM is initialized](https://searchfox.org/mozilla-central/source/devtools/client/responsive/ui.js#150). Since we're not doing away with swap/tunnel until work on RDM fission is complete, we should still preserve the toolWindow property on RDM UI.
For context, this.toolWindow is a reference to the RDM UI’s window, which also happens to be populated with other properties such as `getViewportBrowser` (the function causing the issue), `getViewportSize`, `addInitialViewport`, etc… It’s responsible for holding the RDM UI chrome:// document which is also where the <mozbrowser> iframe is contained. Please see: https://searchfox.org/mozilla-central/source/devtools/client/responsive/index.js for reference on where these properties are added.
Also, now that the RDM fission work requires the removal of <mozbrowser>, this.toolWindow won't be needed to get access to the toolbar UI. The RDM toolbar will be embedded into the browser UI and can be referenced with `this.rdmFrame`.
So this means toolWindow along with any parts of the code using it should be removed when fission work is complete. I believe [Bug 1585096](https://bugzilla.mozilla.org/show_bug.cgi?id=1585096) would be the correct place to do this.
Differential Revision: https://phabricator.services.mozilla.com/D56602
--HG--
extra : moz-landing-system : lando
For some reason the parameterNames was expected as
a prop, but it's available on the function grip
itself.
The rep is fixed, and tests are modified to reflect
this change.
Differential Revision: https://phabricator.services.mozilla.com/D55926
--HG--
extra : moz-landing-system : lando
For some reason the parameterNames was expected as
a prop, but it's available on the function grip
itself.
The rep is fixed, and tests are modified to reflect
this change.
Differential Revision: https://phabricator.services.mozilla.com/D55926
--HG--
extra : moz-landing-system : lando
The failure indicates that there's a pending call
to the server for highlighting while the connection
is being closed.
I guess that's because the test was logging some
nodes, and the mouse position could trigger a
highlight.
Since we don't really need to log those nodes,
this patch only changes one of the expression.
Differential Revision: https://phabricator.services.mozilla.com/D55782
--HG--
extra : moz-landing-system : lando
This only highlights the fact that the front will only
do the heavy work once, since we set the _client property
to null, and the function is guarded against the _client
truthiness.
Differential Revision: https://phabricator.services.mozilla.com/D56524
--HG--
extra : moz-landing-system : lando
These typically indicate a fatal problem for whatever the page is trying to do;
we should give them the appropriate visibility.
Differential Revision: https://phabricator.services.mozilla.com/D56239
--HG--
extra : moz-landing-system : lando
Backed out changeset 06ca873edb4c (bug 1525966)
Backed out changeset 8ff967efc6d6 (bug 1525966)
CLOSED TREE
--HG--
extra : rebase_source : 8fb6432626ea832ed4bf081068d0c1144de066bd
Depends on D55829
In case other rejects are still using strings instead of error objects.
Differential Revision: https://phabricator.services.mozilla.com/D55830
--HG--
extra : moz-landing-system : lando
This will allow Reps to consume those and
display more accurate functions informations.
Differential Revision: https://phabricator.services.mozilla.com/D55928
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This methods is then used in Netmonitor and Animation
panel, where we already had similar functions.
Differential Revision: https://phabricator.services.mozilla.com/D56167
--HG--
extra : moz-landing-system : lando
This revision removes false positives for absolutely-positioned elements using grid item properties. It doesn’t solve identifying an absolutely positioned element in a grid container since this issue would require more consideration when finding the element’s containing block to make it work. For now, inactive CSS will invalidate a grid item property if the element is not a grid item and is not absolutely positioned.
Differential Revision: https://phabricator.services.mozilla.com/D55400
--HG--
extra : moz-landing-system : lando
Accidentally missed to use the fallback value "closest-side closest-side" when needed. Fixed now.
Differential Revision: https://phabricator.services.mozilla.com/D55982
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
