Until Firefox 64 the preference "app.update.auto" controlled if updates
can be downloaded and applied. This changed in Firefox 65, and now the
preference "app.update.disabledForTesting" controls it.
Depends on D13516
Differential Revision: https://phabricator.services.mozilla.com/D13517
--HG--
extra : moz-landing-system : lando
Until Firefox 64 the preference "app.update.auto" controlled if updates
can be downloaded and applied. This changed in Firefox 65, and now the
preference "app.update.disabledForTesting" controls it.
Depends on D13515
Differential Revision: https://phabricator.services.mozilla.com/D13516
--HG--
extra : moz-landing-system : lando
- Unified openContainerNodeInTabs and openURINodesInTabs in PlacesUIUtils into openMultipleLinksInTabs
- Users are now warned when the amount of links to be opened is equal to or exceeds browser.tabs.maxOpenBeforeWarn
Differential Revision: https://phabricator.services.mozilla.com/D12983
--HG--
extra : moz-landing-system : lando
Marionette is a remote protocol which allows to automate the
application. Because it is not only run in CI automation but
also by users outside of the tree, the flag "Cu.isInAutomation"
cannot be used to determine if updates can be downloaded and
installed.
But it can b achieved by relying on the "running" state as
exposed by Marionette through the nsIMarionette interface.
Differential Revision: https://phabricator.services.mozilla.com/D13515
--HG--
extra : moz-landing-system : lando
The desktop1604-test image doesn't build deterministically, primarily
due to not pinning APT package indices. Rebuilding it from scratch
today results in at least 2 problems causing test failures. One has
to do with a renamed media device. Another is not yet determined but
is causing the Android emulator to fail.
Various people have spent several hours trying to debug the failures.
There are some leads. But no obvious solution is in sight. Various
code landings are blocked on this.
Enough is enough.
This commit modifies desktop1604-test so it inherits from a base image
that contains the last good build of the image. Other minimal
modifications were made to enable the image to build with a populated
base image.
This is a gross hack. It is equivalent to sweeping dust under the rug.
But it gets the job done. It should unblock various code landings.
The base image was imported from task K-qJkvIqQQ-EFK8-4zg_nA.
The intent is to undo this hack ASAP by fixing the base image. This is
tracked by bug 1511527.
As part of developing this patch, I ran into at least two different
issues building the Docker image using the last known good image as a
base.
On my desktop machine using btrfs for Docker storage, the image failed to
build due to a "failed to export image: failed to create image: failed
to get layer XXX: layer does not exist" error.
In CI, I ran into separate issues where some `rm` invocations didn't
work. Why, I have no clue.
I ran a `docker export | docker import` of a running container with
the good image to produce a new Docker image with just the filesystem
contents. This had the effect of squashing the original Docker image
into a single layer. For reasons I can't explain, this made the image
build in CI. Welcome to the wonderful world of Docker bugs, everyone.
Differential Revision: https://phabricator.services.mozilla.com/D13600
--HG--
extra : moz-landing-system : lando
Change nsMacUtilsImpl::GetAppPath() to not depend on the app bundle ending in ".app".
Differential Revision: https://phabricator.services.mozilla.com/D13682
--HG--
extra : moz-landing-system : lando
The strict category should block third-party tracking cookies instead of all third-party cookies. This changes the requirements to match that category, so existing strict users will be moved to custom.
Differential Revision: https://phabricator.services.mozilla.com/D13325
--HG--
extra : moz-landing-system : lando
This change cleans up a lot of the getCurrentDisplay's logic which was unnecessarily
complex, it seems.
It also extracts the logic to walk up the DOM to find flex/grid containers to a
reusable functions.
Finally, this new extracted function is now used in the walker to determine if a text
node can be inlined in its parent element or not.
Differential Revision: https://phabricator.services.mozilla.com/D13677
--HG--
extra : moz-landing-system : lando
When a declaration is disabled, it is tracked as removed in the Changes panel.
When deleting a disabled declaration, we take care not track it as removed again.
Includes stricter checks when matching previously tracked added and removed declarations.
Differential Revision: https://phabricator.services.mozilla.com/D13616
--HG--
extra : moz-landing-system : lando
This removes the instrumentation to test the basic telemetry for the Changes panel (open count, time opened).
Differential Revision: https://phabricator.services.mozilla.com/D13691
--HG--
extra : moz-landing-system : lando
Calling this function is just a waste of time since we will check
third-partiness a few statements further down.
Differential Revision: https://phabricator.services.mozilla.com/D13500
--HG--
extra : moz-landing-system : lando
Some keyboard layouts which have dead keys may handle dead key composition
asynchronously. In this case, they don't rely on IME like iBus/Fcitx.
As far as I've tested, German (QWERTY) keyboard layout is one of such
keyboard layout. This returns true when gtk_im_context_filter_keypress()
is called for a base character input (like "a"). Then, it synthesizes
GDK_KEY_PRESS event without any key information such as:
> { type=GDK_KEY_PRESS, keyval=(null), unicode=0x0, state=, time=0,
> hardware_keycode=0, group=0 }
So, this is not marked as IBUS_IGNORED_MASK nor FcitxKeyState_IgnoredMask
by IME, but we should ignore this event since we should've already dispatched
"keydown" event for the preceding "a" key event, and anyway "keydown" event
for the synthesized event does not make sense for any web apps.
This patch makes IMContextWrapper::OnKeyEvent() ignore such key event, i.e.,
when it's in a dead key sequence, and GDK_KEY_PRESS does not have enough
information, e.g., hardware_keycode shouldn't be 0 especially for printable
keys. Therefore, this patch make it check only hardware_keycode value and
gdk_keyval_to_unicode(aEvent->keyval) value.
If some keyboard layouts would send the original key event as is, we would
need to do more, but currently, this is enough and safe to land this timing.
Differential Revision: https://phabricator.services.mozilla.com/D13656
--HG--
extra : moz-landing-system : lando
This means that for the File URI content process, we end up closing RDM if the page
navigates. This appears to be an acceptable trade-off, as this is the behaviour we've
been shipping since bug 1453519 landed (Firefox 61).
Differential Revision: https://phabricator.services.mozilla.com/D13331
--HG--
extra : moz-landing-system : lando
Titlebar (StyleAppearance::MozWindowTitlebar) style depends on toplevel window focus
and we need to redraw it when toplevel window focus changes.
Unfortunately according to https://gitlab.gnome.org/GNOME/gtk/issues/1395
the toplevel window focus can't be used here as we can have active but unfocused
toplevel window during drag & drop.
Gtk+ controls window active appearance by window-state-event signal
but gecko uses focus-in/out signals, so we need to repaint the titlebar
when window-state-event comes *after* focus-in/out signals.
We can't call mWidgetListener->WindowActivated() (and WindowDeactivated())
as it was already called from focus-in/out handlers before window-state-event.
Depends on D13051
Differential Revision: https://phabricator.services.mozilla.com/D13052
--HG--
extra : moz-landing-system : lando
This is a workaround for https://gitlab.gnome.org/GNOME/gtk/issues/1395
Gtk+ controls window active appearance by window-state-event signal
but gecko uses focus-in/out signals.
So we need to set the the titlebar state
when window-state-event comes *after* focus-in/out signals.
Differential Revision: https://phabricator.services.mozilla.com/D13051
--HG--
extra : moz-landing-system : lando
- Don't create wl_subsurface in map event but rather when it's requested by compositor.
- Don't create wl_surface at nsWindow::OnExposeEvent but check ready_to_draw instead.
- Rename parent_surface_committed_handler to frame_clock_after_paint_handler.
- Rename parent_surface_committed to ready_to_draw.
- Rename needs_clear to surface_needs_clear.
Depends on D13404
Differential Revision: https://phabricator.services.mozilla.com/D13405
--HG--
extra : moz-landing-system : lando
update fluent.syntax to 0.9.0
update compare-locales to 5.0.2
update fluent.migrate to https://hg.mozilla.org/l10n/fluent-migration/rev/3877312dc1f4
This includes migration-specific fixes for bugs 1491591, 1491833, 1491859, 1496127
All of these changes have been reviewed before in their respective upstream
repositories.
Differential Revision: https://phabricator.services.mozilla.com/D11861
--HG--
extra : moz-landing-system : lando
