This makes the worst case for cascade performance slightly more
expensive (4 rather than three declaration walks), but my hope is that
it will make the average case faster, since the best case is now just
two walks instead of three, and writing mode properties are somewhat
rare.
This needs a test, but needs to wait until the writing-mode dependent
viewport units land (will wait to land with a test).
Differential Revision: https://phabricator.services.mozilla.com/D143261
I tested client all the way back to Ubuntu 18 LTS and seems to work
fine, any reason not to try this?
This fixes some weird overdrawing on the window corners on GNOME+X11.
Differential Revision: https://phabricator.services.mozilla.com/D139556
- stop mixing telemetry data with other information in `loginsFooter.comment`, store telemetry information on dedicated field inside `loginsFooter.comment.telemetryEventData`
- provide `comment` from the selected autocomplete item as data to `autocomplete-will-enter-text` notification. This enables single place of processing for both mouse click and ENTER key press.
- various autocomplete items can specify `comment.fillMessageName` and `comment.fillMessageData` to be passed to LoginManagerParent for processing and fill value generation. This enables lazy decryption, generating email aliases by Relay, integrating with external password managers, etc. by using async call.
- `gAutoCompleteListener` does not need to listen for ENTER key and `FormAutoComplete:PopupOpened`/`FormAutoComplete:PopupClosed` events anymore
- `MozAutocompleteRichlistitemLoginsFooter`, `MozAutocompleteImportableLearnMoreRichlistitem` and `MozAutocompleteImportableLoginsRichlistitem` in toolkit/content/widgets/autocomplete-richlistitem.js do not need to listen to click events and replicate code from LoginManagerParent
Differential Revision: https://phabricator.services.mozilla.com/D142912
This was added because ElementaryOS themes have bright selected
backgrounds and dark text (for light themes), but we use the accent
colors for some places where that is not appropriate and a darker color
is, like checkbox backgrounds or form control borders.
Bug 1741293 split the selected item text / background colors from the
accent colors, so now we can use the real selected item colors and only
do this on the accent color. I wanted to split this out from bug 1741293
to minimize behavior changes in there.
Also while at it, blend opaque foreground with the appropriate
background on EnsureColorPairIsOpaque.
Differential Revision: https://phabricator.services.mozilla.com/D143255
Android P+ supports magnify glass and Chrome already supports it.
When accessible caret events are fired for pressing or dragging it, we show
Android's magnifying glass.
Differential Revision: https://phabricator.services.mozilla.com/D137966
To support magnifying glass on GeckoView, I would like to add `dragcaret`
event and, clientX and clientX in CaretStateChangedEvent chrome event.
Actually, accessible caret fires `presscaret` and `releasecaret` when
accessbile caret is pressed or released. But when dragging this caret, no
chrome event is fired. Since magnifying glass listens to moving this caret,
I would like `dargcaret` for GeckoView.
Also, Users' dragging point is necessary to set better position of magnifying
glass windows. So I also want client point of dragging point on `presscaret`
and `dragcaret` event.
This event and properties are on layout.accessiblecaret.magnifier.enabled=true,
So this can be only for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D137965
If the overall surface dirty rect is large enough to include prims
on texture surface tasks, but those texture surface tasks are not
dirty, we could accidentally consider a primitive visible and needing
to be rendered. If that prim has a clip mask render task, but there
are no invalid picture cache tiles, there are no parent tasks for
the clip mask tasks to be attached to, which means the render task
graph never determines a parent pass to free those tasks on.
Differential Revision: https://phabricator.services.mozilla.com/D143227
Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.
The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html
The proper fix is to have Intel specific driver version parsing.
Differential Revision: https://phabricator.services.mozilla.com/D143248
Fixes for these points from the a11y review of Private Browsing:
-the download button should have a border (color: ButtonText) when it is hovered so the text itself doesn’t bleed into the background
-the border on the close button should use ButtonText
-the google play and app store buttons in the dialog seem to be images, and the images already have borders so adding the button border like we’d normally makes it look fuzzy/visually indistinct. Ideally I’d remove the border from the image and rely on the CSS styling to add the (dynamic) border back in, but we could also remove the border in HCM since this content wont be adaptive anyway (and I think having the additional border here is actually harming the UX)
Differential Revision: https://phabricator.services.mozilla.com/D143092
Emilio Cobos Álvarez
Cristian Tuns
Jeff Muizelaar
Joel Maher
Andrew Osmond
Sergey Galich
Jens Stutte
Julian Descottes
Hubert Boma Manilla
Norisz Fay
André Bargull
Mozilla Releng Treescript
Makoto Kato
Butkovits Atila
Glenn Watson
Ryan VanderMeulen
alwu
Andreea Pavel
Oriol Brufau
a153
Shane Caraveo
Emily McMinn