These tests appear to have been previously failing as we would download
the resources being fetched due to their MIME type, rather than
rendeirng them in-browser, meaning that the reporting would behave
differently.
The change to support arbitrary text/ MIME types appears to have fixed
this, and now the tests pass as expected.
Depends on D212078
Differential Revision: https://phabricator.services.mozilla.com/D212620
This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.
This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.
Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D212078
This was a typo introduced in bug 1209658. Previously the code would be
checking `gXULTypes`. Support for XUL documents has since been removed from
Gecko, so the code is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D212077
This patch adds a lull-schedule attribute to some browsertime live-site tasks so that we can start testing lull-scheduling. The lull-schedule attribute will be used to denote how frequently a particular task should run. The lull-schedule attribute exists first as a raptor specific setting, and is then added to the `extra` section so that we can make use of it in the `mozci` module.
Differential Revision: https://phabricator.services.mozilla.com/D212202
Co-author/investigator: Tim Giles <tgiles@mozilla.com>
Delay sychronous loading of ESM based custom elements until the
DOMContentLoaded event. With D212190--which this patch depends on--the
components that have already been used on the page will be synchronously
loaded when customElements.setElementCreationCallback is registered.
Differential Revision: https://phabricator.services.mozilla.com/D212191
Co-author/investigator: Tim Giles <tgiles@mozilla.com>
When using SetElementCreationCallback with ESM based custom elements we
are seeing a performance regression vs when we previously required
manually adding a <script type="module"> for the import to the page.
To work around this issue we can delay registering the callback until
the DOMContentLoaded event which improves performance, presumably due to
reduced thrashing from HTML parsing to JS parsing.
With that change however any components that were encountered before the
DOMContentLoaded event will not be loaded or upgraded until the next
time a component of that type is created.
This patch updates the SetElementCreationCallback function to
immediately invoke the callback if there are candidate elements of that
type to upgrade.
Differential Revision: https://phabricator.services.mozilla.com/D212190
I verified that quitting while the synchronous version of the dialog is active doesn't hang, so we're not re-regressing bug 1898718.
Differential Revision: https://phabricator.services.mozilla.com/D212189
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
Most OS APIs want a cluster when they ask for a "character", except ATK.
Rather than altering BOUNDARY_CHAR, I added a new BOUNDARY_CLUSTER.
Aside from being less risky and causing less churn, there are cases internally where we want to move a TextLeafPoint by character; e.g. to explicitly move to the next/previous Accessible or to move to the next/previous character in an abstract way without worrying about Accessible boundaries.
Calculating clusters is more expensive, so it doesn't make sense to move by cluster in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D212517
The datetime input is inconsistent with other inputs when using spoof
English: its placeholder is not translated, unlike the default values
and texts of all the other inputs.
Differential Revision: https://phabricator.services.mozilla.com/D201726
