When a page is refreshed, the inspector fonts associated with targets within are destroyed and recreated.
The node picker didn't observe for this behavior. When a page was refreshed, it kept picking against dead fronts and ignored the newly created fronts, thus leaving users confused. This is an issue in popular web dev workflows like Hot Module Reloading, where the page may end up being refreshed. See [Bug1352121#c4](https://bugzilla.mozilla.org/show_bug.cgi?id=1352121#c4)
This patch makes the node picker listen for targets and inspector fronts as they become available or get destroyed. If node picking isn't explicitly stopped by either clicking a node or pressing the Escape key, node picking continues onto the refreshed page or to new page (same behavior as in Firefox Release).
Differential Revision: https://phabricator.services.mozilla.com/D92779
By Bug 1661189, AndroidHardwareBuffer owning TextureHosts became to be stored in mTextureHostsUntilRenderSubmitted.
AndroidHardwareBuffer usage is not enabled on gecko.
Differential Revision: https://phabricator.services.mozilla.com/D93050
when there is no composition, `IMEStateManager::HandleSelectionEvent()` calls
`TextComposition::HandleSelectionEvent()` with `BrowserParent` which is
retrieved from `aEventTargetContent` which is focused content in the main
process. This means that `eSetSelection` event is handled in root document
of the focused tab when there is no composition. However, following composition
events will go to focused `BrowserParent`, i.e., if an OOP iframe has focus
in the tab, `eSetSelection` event won't be handled in it. Therefore, IME
always fails to replace existing text with new composition.
This patch makes both `IMEStateManager::HandleSelectionEvent()` and
`PresShell::EventHandler::DispatchEventToDOM()` use
`IMEStateManager::GetActiveBrowserParent()` for sending both `eSetSelection`
and composition events to same process. Additionally, this patch make
`IMEStateManager::GetActiveBrowserParent()` returns
`IMEStateManager::sFocusedIMEBrowserParent` when it's set to non-nullptr
because native IME tries to modify the editor which enabled IME context.
On the other hand, for making the behavior safer, we should make
`eCompositionStart` event have replacing range optionally. I filed
bug 1669907 to change the design, but it requires several non-tiny patches.
Once we fix it, we can write automated tests for this simply, but without
the fix, I need to write too many lines with low level API, and it becomes
unnecessary after fixing the bug. Therefore, I give up to write a test
for this for now.
Differential Revision: https://phabricator.services.mozilla.com/D93053
Unfortunately, there is no official way to detect whether browser supports
or not `beforeinput` event in the wild because Chromium does not support
`onbeforeinput` event handler attribute. On the other hand, we're the
last browser vendor which does not support `beforeinput` event, and we
make `InputEvent.getTargetRanges()` enabled only when `beforeinput` event
because it returns meaningful value only when the event type is `beforeinput`.
So, web apps can detect `beforeinput` event support with checking type of
or existence of it instead. However, in our experience, it's guessed what
a lot of web apps check whether "Firefox" or not to consider whether it
can use `beforeinput` events. If so, we need to announce shipping
`beforeinput` event and the way to feature detection before actually shipping
it. Otherwise, we wouldn't get enough feedback from testers.
First of all for shipping `beforeinput` events, we should collect how much
web apps which use `HTMLEditor` use `beforeinput` event when it's enabled,
and how much web apps use mutation events or mutation observer instead of
`beforeinput` events even when it's enabled.
Honestly, I'd like to collect URLs which don't use `beforeinput` event, but
use mutation events or mutation observer. But it's really sensitive data
so that I believe that we shouldn't collect it.
Differential Revision: https://phabricator.services.mozilla.com/D92548
There is similar API in `Document`, but they indicate whether a node has been
observed by any mutation receiver, not only by `MutationObserver` of JS.
However, I'd like to know the percentage of web apps which use
`MutationObserver`, but not use `beforeinput` events. Therefore, this patch
adds similar API into `nsPIDOMWindowInner` as same as `beforeinput` and
ignores `MutationObserver`s which are created by chrome script and addons.
Differential Revision: https://phabricator.services.mozilla.com/D92547
When `HTMLEditor` instances are destroyed, I'd like to collect how much
instances are worked with `beforeinput` event listeners. Before adding such
telemetry probe, this patch adds methods to set/get whether a `beforeinput`
event listener has had added or not to `nsPIDOMWindowInner`.
Differential Revision: https://phabricator.services.mozilla.com/D92546
- What this patch does:
Send a "download-suspended-by-cache" signal to the media-element paired
with a cloned cache-stream right after the cache-stream is cloned. That
signal help the media-element to decide if it's ready to enter the
HAVE_ENOUGH_DATA state and fire a "canplaythrough" event.
- Why this patch is needed:
It solves a WPT timeout issue. That WPT test waits a "canplaythrough"
event.
- What problem this patch solves is:
This patch addresses the problem mentioned in [1].
Each media-element pairs with a cache-stream downloading the data it
needs. When the data-download of a cache-stream gets suspended, the
media-element paired with the cache-stream should be notified. This
notification is one of the factor to move the ready-state of the
media-element to HAVE_ENOUGH_DATA. However, the media-element paired
with a cloned cache-stream may never receive this notification. And the
worst is that it may never have a chance to download enough data it
needs to move the ready-state to HAVE_ENOUGH_DATA as well at the same
time, in the case mentioned below.
This can happen when a media-element paired with a cloned cache-stream
is created after the cache is full, and all of the cache-streams are
suspended. (Cloned cache-stream is a cache-stream cloned from another
cache-stream that shares the same underlying data with it since their
paired media-elements have the same `src` (of `HTMLMediaElement`)).
"canplaythrough" event is fired when the ready-state is transited to
HAVE_ENOUGH_DATA. As a result, it will never be fired in this case.
In usual case, if the cache-stream gets suspended from non-suspended, it
will send a "download-suspended-by-cache=true" signal to its paired
media-element when running `MediaCache::Update()`. In fact, all other
cache-streams sharing the same underlying data will send this signal at
the same time if necessary. (Later, once the cache-stream is resumed
from suspended to non-suspended it will send a
"download-suspended-by-cache=false" signal to its paired media-element.
All other cache-streams sharing the same underlying data will do the
same if necessary.) The media-element keeps tracking that signal it
receives. After the first-frame of the media-element is loaded, the
ready-state of the media-element will be transited to HAVE_ENOUGH_DATA
by force if the signal is true. (Otherwise, the ready-state will be
inferred by other information.)
When cloning a cache-stream from another one, the cloned cache-stream is
suspended by default. If it's added to a jammed cache that all of the
cache-streams are suspended since the cache is full, then it never has a
chance to fire the "download-suspended-by-cache" signal. Both its
source-stream and itself have no status-change between suspended and
non-suspended, so `MediaCache::Update` is unable to send the signal.
In this case, we should force the media-element paired with the newly
cloned cache-stream transits its ready-state to HAVE_ENOUGH_DATA, which
follows the existing mechanism, by queueing a status-change-update when
cloning the stream. The status-change-update will be run in the
`MediaCache::Update` and it will check what the signal should be sent.
Once the "download-suspended-by-cache=true" is sent, the
"canplaythrough" event of the media-element can be dispatched after
its first-frame is loaded. (The event listeners can possibly make the
media-element starts playing, which is likely to cause a cache-seek that
can revitalize the cache eventually.)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1646719#c5
Differential Revision: https://phabricator.services.mozilla.com/D92125
Add some logs that can help us to check how many cache-streams are
suspended and the working status in `MediaCache::Update`
Differential Revision: https://phabricator.services.mozilla.com/D92124
With this change SHIP seems to also fix an issue with hashchange event - those are triggered now
more consistently than without SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D92993
Some recent change apparently made the multiprocessing code reenter
python with the arguments `-s -c "..."` instead of `-c "..."`, which
broke the assumption of the hack.
Differential Revision: https://phabricator.services.mozilla.com/D93060
Due to font cache issues with the ub18-test docker image in
TaskCluster the first startup of Firefox sometimes takes more
than 15s.
As workaround for now just start Firefox once before running
Puppeteer unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D93110
We blocked the older versions of database.dll as Bug 1566109 in 2019,
but the same crash is still happening with the newer versions.
We decided to block all versions because crashing in the middle of printing
or file uploading is not acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D92988
If margins are manually set to negative entries or if the selected printer
had bad values, we need to correctly reset the pref value to valid default
margins.
Differential Revision: https://phabricator.services.mozilla.com/D92465
Due to font cache issues with the ub18-test docker image in
TaskCluster the first startup of Firefox sometimes takes more
than 15s.
As workaround for now just start Firefox once before running
Puppeteer unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D93110
Mike Hommey
Razvan Caliman
Makoto Kato
Timothy Nikkel
Bas Schouten
sotaro
Razvan Maries
Masayuki Nakano
Chun-Min Chang
Olli Pettay
Richa Sharma
Tim Nguyen
Mike Conley
Henrik Skupin
Toshihito Kikuchi
Andreea Pavel
Cosmin Sabou
Ricky Stewart
Neil Deakin
Agi Sferro
Jeff Muizelaar
Kris Maglione
Emma Malysz
Chris Martin
Nicolas B. Pierron