Inform the user about why is this feature disabled and what to do to enable it.
Differential Revision: https://phabricator.services.mozilla.com/D8545
--HG--
extra : moz-landing-system : lando
Since we do now have the list of Javascript keywords, we
import it from webconsole autocomplete service and send
the keywords matching the current expression to the client.
Differential Revision: https://phabricator.services.mozilla.com/D8709
--HG--
extra : moz-landing-system : lando
This list is generated from /js/src/frontend/ReservedWords.h,
which is already used on the platform to generate list of js
reserved words.
This list will be used in the console autocomplete code to
expose those keywords to the user.
Differential Revision: https://phabricator.services.mozilla.com/D8998
--HG--
extra : moz-landing-system : lando
One important unrelated change this makes is that previously (in my other patches), the only "@" aliases we recognized were the internal "@" aliases in nsSearchService. While I was working on the new test here I realized that engines with user (or test) aliases that start with "@" aren't recognized as having "@" aliases, but why not IMO.
Differential Revision: https://phabricator.services.mozilla.com/D9074
--HG--
extra : moz-landing-system : lando
This bug touches just about every part of the urlbar: UnifiedComplete, the autocomplete binding, the formatter, CSS.
This builds on the patches in bug 1496814 and bug 1496811.
Differential Revision: https://phabricator.services.mozilla.com/D8948
--HG--
extra : moz-landing-system : lando
- Update 'Pick an element' icon with bigger arrow, background in active state
- Update 'Pick an accessible element' icon with pixel-fitted design, background in active state
- Update 'RDM' icon with background in active state
- Use context-stroke to enable design changes, instead of a different URL, to avoid a visual glitch
Differential Revision: https://phabricator.services.mozilla.com/D9113
--HG--
extra : moz-landing-system : lando
The log we currently receive are not really
actionable (we are using ok, so we don't know
what the received value actually is). Switching
to is should give us what the value is when the
test fails, which might help us fix the failure.
Differential Revision: https://phabricator.services.mozilla.com/D9270
--HG--
extra : moz-landing-system : lando
exception_button can technically be clicked on the old error pages, too, but conditionally
checking for the cert exception window to pop up is a bit overkill for this temporary workaround.
Ideally we would remove this pref soon anyway.
Differential Revision: https://phabricator.services.mozilla.com/D9243
--HG--
extra : moz-landing-system : lando
When a CompositorBridgeParent receives a force first paint message, it
sets the flag on the AsyncCompositionManager, which notifies the
widget code at the next composite via
UiCompositorControllerParent::NotifyFirstPaint().
With webrender, this is crashing as there is no
AsyncCompositionManager. And even if it weren't crashing, the widget
will never receive the first paint message, so it never uncovers its
content.
This change ensures the widget receives the first message when
webrender is enabled. CompositorBridgeParent will set the flag on its
WebRenderBridgeParent, which will set the flag on the next received
display list. When the WebRenderBridgeParent flushes the corresponding
transaction, it calls UiCompositorcontrollerParent::NotifyFirstPaint,
to ensure the widget code gets the message.
Differential Revision: https://phabricator.services.mozilla.com/D9250
--HG--
extra : moz-landing-system : lando
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
--HG--
extra : moz-landing-system : lando
The stop() function is apparently being called multiple times at the end of a test run, causing us to sometimes attempt to remove device forwards that were removed in an earlier stop() attempt but before the conditions checked in stop() to remove the device forwards get changed. This caused a traceback to be printed out at the end of every test run, complaining about attempts to remove device forwards that don't exist.
Rather than dig through to figure out why/where stop() is getting called twice, this patch just papers over the issue by making sure there is at least one device forward still listed before attempting to remove them.
Differential Revision: https://phabricator.services.mozilla.com/D9175
--HG--
extra : moz-landing-system : lando
