This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
Done:
- Provided spinner component with expected ARIA roles and properties for a Spinbutton pattern
- Ensured the programmatic and on-screen visibility is handled when a Spinner dialog is opened/closed
- Provided localized strings for controls of the Spinner
- Updated markup of the Spinner dialog to ensure logical keyboard navigation and consistent on-screen presentation
- Handled live region for the month-year button with and without spinners visible to avoid redundant announcements
- Added tests for the month-year spinner and its localization
Further patches:
1. Pt.4 - Ensure keyboard support in accordance with the ARIA Design Practices 1.2
Depends on D139980
Differential Revision: https://phabricator.services.mozilla.com/D139981
Done:
- Changed DateTimePicker markup to HTML Table with ARIA Grid properties
- Updated CSS for consistency
- Provided localized strings for controls of the Datepicker itself and its Calendar widget
- Added tests for the datepicker markup and its localization
This patch is for HTML structure to comply with ARIA Design Practices 1.2 only.
Further patches:
- Pt.2 - Update month-year spinner dialog to follow the ARIA design pattern
- Pt.3 - Replace Reset button with a Calendar button to toggle the datepicker's visibility
- Pt.4 - Ensure keyboard support and proper focus behavior for both parts of the widget
Differential Revision: https://phabricator.services.mozilla.com/D139980
This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
Done:
- Provided spinner component with expected ARIA roles and properties for a Spinbutton pattern
- Ensured the programmatic and on-screen visibility is handled when a Spinner dialog is opened/closed
- Provided localized strings for controls of the Spinner
- Updated markup of the Spinner dialog to ensure logical keyboard navigation and consistent on-screen presentation
- Handled live region for the month-year button with and without spinners visible to avoid redundant announcements
- Added tests for the month-year spinner and its localization
Further patches:
1. Pt.4 - Ensure keyboard support in accordance with the ARIA Design Practices 1.2
Depends on D139980
Differential Revision: https://phabricator.services.mozilla.com/D139981
Done:
- Changed DateTimePicker markup to HTML Table with ARIA Grid properties
- Updated CSS for consistency
- Provided localized strings for controls of the Datepicker itself and its Calendar widget
- Added tests for the datepicker markup and its localization
This patch is for HTML structure to comply with ARIA Design Practices 1.2 only.
Further patches:
- Pt.2 - Update month-year spinner dialog to follow the ARIA design pattern
- Pt.3 - Replace Reset button with a Calendar button to toggle the datepicker's visibility
- Pt.4 - Ensure keyboard support and proper focus behavior for both parts of the widget
Differential Revision: https://phabricator.services.mozilla.com/D139980
This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
Done:
- Provided spinner component with expected ARIA roles and properties for a Spinbutton pattern
- Ensured the programmatic and on-screen visibility is handled when a Spinner dialog is opened/closed
- Provided localized strings for controls of the Spinner
- Updated markup of the Spinner dialog to ensure logical keyboard navigation and consistent on-screen presentation
- Handled live region for the month-year button with and without spinners visible to avoid redundant announcements
- Added tests for the month-year spinner and its localization
Further patches:
1. Pt.4 - Ensure keyboard support in accordance with the ARIA Design Practices 1.2
Depends on D139980
Differential Revision: https://phabricator.services.mozilla.com/D139981
Done:
- Changed DateTimePicker markup to HTML Table with ARIA Grid properties
- Updated CSS for consistency
- Provided localized strings for controls of the Datepicker itself and its Calendar widget
- Added tests for the datepicker markup and its localization
This patch is for HTML structure to comply with ARIA Design Practices 1.2 only.
Further patches:
- Pt.2 - Update month-year spinner dialog to follow the ARIA design pattern
- Pt.3 - Replace Reset button with a Calendar button to toggle the datepicker's visibility
- Pt.4 - Ensure keyboard support and proper focus behavior for both parts of the widget
Differential Revision: https://phabricator.services.mozilla.com/D139980
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
Done:
- Provided spinner component with expected ARIA roles and properties for a Spinbutton pattern
- Ensured the programmatic and on-screen visibility is handled when a Spinner dialog is opened/closed
- Provided localized strings for controls of the Spinner
- Updated markup of the Spinner dialog to ensure logical keyboard navigation and consistent on-screen presentation
- Handled live region for the month-year button with and without spinners visible to avoid redundant announcements
- Added tests for the month-year spinner and its localization
Further patches:
1. Pt.4 - Ensure keyboard support in accordance with the ARIA Design Practices 1.2
Depends on D139980
Differential Revision: https://phabricator.services.mozilla.com/D139981
Done:
- Changed DateTimePicker markup to HTML Table with ARIA Grid properties
- Updated CSS for consistency
- Provided localized strings for controls of the Datepicker itself and its Calendar widget
- Added tests for the datepicker markup and its localization
This patch is for HTML structure to comply with ARIA Design Practices 1.2 only.
Further patches:
- Pt.2 - Update month-year spinner dialog to follow the ARIA design pattern
- Pt.3 - Replace Reset button with a Calendar button to toggle the datepicker's visibility
- Pt.4 - Ensure keyboard support and proper focus behavior for both parts of the widget
Differential Revision: https://phabricator.services.mozilla.com/D139980
This has some provision to continue working if the tab is closed or reloaded,
but it's not fool proof. Eventually we might want to move this to a service, but
it's already very useful as it is.
Differential Revision: https://phabricator.services.mozilla.com/D160213
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
Note that, for the most part, this isn't meant to change behavior. It is just meant to eliminate race conditions and fix some bugs. However, a tiny bit of behavior has been changed.
Previously, the fallback error codes used to potentially populate nsIUpdate.statusText were 200 in Checker.onError (corresponding to "Update XML file malformed") and 404 in Checker.onLoad (corresponding to "Update XML file not found"). These really seem backwards to me. Especially in the Checker.onLoad case, where we basically use that as the fallback if we fail to parse the update XML. So the codes have effectively been reversed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D159302
Note that, for the most part, this isn't meant to change behavior. It is just meant to eliminate race conditions and fix some bugs. However, a tiny bit of behavior has been changed.
Previously, the fallback error codes used to potentially populate nsIUpdate.statusText were 200 in Checker.onError (corresponding to "Update XML file malformed") and 404 in Checker.onLoad (corresponding to "Update XML file not found"). These really seem backwards to me. Especially in the Checker.onLoad case, where we basically use that as the fallback if we fail to parse the update XML. So the codes have effectively been reversed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D159302
Incorporates the "Places Database Statistics" table from `chrome://browser/content/places/interactionsViewer.html` into the `about:support` page, under the existing "Places Database" table. The table is hidden by default, and it can be toggled on/off using a button. Table contents will always be part of the "Copy text to clipboard" export, regardless of visibility.
Try Job: https://treeherder.mozilla.org/jobs?revision=923a9df8c477f6e2b1f0a2fee3b0291ddbdd32e3&repo=try
Initial state:
{F4177493}
After clicking "Show Statistics":
{F4177495}
Text export:
{F4177496}
Differential Revision: https://phabricator.services.mozilla.com/D158200
Note that, for the most part, this isn't meant to change behavior. It is just meant to eliminate race conditions and fix some bugs. However, a tiny bit of behavior has been changed.
Previously, the fallback error codes used to potentially populate nsIUpdate.statusText were 200 in Checker.onError (corresponding to "Update XML file malformed") and 404 in Checker.onLoad (corresponding to "Update XML file not found"). These really seem backwards to me. Especially in the Checker.onLoad case, where we basically use that as the fallback if we fail to parse the update XML. So the codes have effectively been reversed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D159302
Incorporates the "Places Database Statistics" table from `chrome://browser/content/places/interactionsViewer.html` into the `about:support` page, under the existing "Places Database" table. The table is hidden by default, and it can be toggled on/off using a button. Table contents will always be part of the "Copy text to clipboard" export, regardless of visibility.
Try Job: https://treeherder.mozilla.org/jobs?revision=923a9df8c477f6e2b1f0a2fee3b0291ddbdd32e3&repo=try
Initial state:
{F4177493}
After clicking "Show Statistics":
{F4177495}
Text export:
{F4177496}
Differential Revision: https://phabricator.services.mozilla.com/D158200
The data included in the `Reader:AddButton` message used by SaveToPocket.jsm is slightly modified, as it now includes a localization identifier rather than a preformatted label.
Differential Revision: https://phabricator.services.mozilla.com/D158575
The data included in the `Reader:AddButton` message used by SaveToPocket.jsm is slightly modified, as it now includes a localization identifier rather than a preformatted label.
Differential Revision: https://phabricator.services.mozilla.com/D158575
After the preceding changes, brand.dtd has no more actual users and may be removed.
One mochitest is switched to use a different DTD file which will still remain in the tree.
The dependency in aboutSupport.xhtml appears to have been accidentally left in when its localization was migrated to Fluent.
Differential Revision: https://phabricator.services.mozilla.com/D156668
Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
It's later in the cycle than we would want to enable this string, but there's
no reason not to go ahead and land it. We'll switch it on later.
The purpose of this change is to make the string shorter, primarily in locales
where "browse" or "Picture-in-picture" translates to something significantly
longer. This should reduce the height of the full explainer box for those
locales, hopefully decreasing the chance of it running into the video controls
or some other page element.
Differential Revision: https://phabricator.services.mozilla.com/D157265
Create a new type of utility process which would be used for media
foundation media engine CDM usage. The media engine is a media pipeline
provided by the Windows Media Foundation, and our final goal is to use
that pipeline to play encrypted content in order to achieve Widevine L1
protection to allow users to watch high resolution videos.
Differential Revision: https://phabricator.services.mozilla.com/D154033
Except for the close-notification-message, all of the notification.dtd
strings are only used by popupnotification.js. Accordingly, the strings
are migrated to two different FTL files.
Differential Revision: https://phabricator.services.mozilla.com/D154890
The localization file is moved to `content/` to make it more clear that it's not intended to be localised.
For the same reason, no Fluent migration script is included as there are no localised strings to migrate.
Differential Revision: https://phabricator.services.mozilla.com/D155702
I was not able to test this manually as it's a Windows-only component,
but it's at least somewhat covered by the tests in
browser/components/preferences/tests/browser_change_app_handler.js
which pass in CI.
Differential Revision: https://phabricator.services.mozilla.com/D155105
After the preceding change, the editMenuOverlay strings are only used by the styleeditor.
Therefore it makes sense to migrate them here specifically to its localization file.
Differential Revision: https://phabricator.services.mozilla.com/D155449
As the widget requires the individual fields' placeholder values to
be known during their build, the DOMLocalization instance used here
needs to have sync methods enabled. For the same reason, the
placeholder strings need to be separate messages, rather than
attributes on the same message as the corresponding label.
Differential Revision: https://phabricator.services.mozilla.com/D154448
The alert.properties file is not migrated here, as its contents are
also used by OS-specific alert notifications:
- widget/cocoa/OSXNotificationCenter.mm
- widget/windows/ToastNotificationHandler.cpp
Differential Revision: https://phabricator.services.mozilla.com/D154380
This migrates the remaining strings from both commonDialog.dtd and
dialogOverlay.dtd into a single new tabprompts.ftl file, as they are
only used by TabModalPrompt.
Differential Revision: https://phabricator.services.mozilla.com/D154423
This migrates the remaining strings from both commonDialog.dtd and
dialogOverlay.dtd into a single new tabprompts.ftl file, as they are
only used by TabModalPrompt.
Differential Revision: https://phabricator.services.mozilla.com/D154423
Messages used by the `about:addons` page are migrated to `aboutAddons.ftl`.
Unused messages are dropped, as is the `get_string()` helper from `test/browser/head.js`.
Differential Revision: https://phabricator.services.mozilla.com/D131793
This "Firefox 100 User-Agent String" setting was added in bug 1748798 to help test if sending a "Firefox 100" UA string causes any major webcompat problems.
The "general.useragent.forceVersion100" pref will be removed in the next changeset.
Differential Revision: https://phabricator.services.mozilla.com/D140460
The Nightly experiment's description:
> Firefox 100 User-Agent String
>
> Make Nightly send websites a User-Agent string that pretends to be Firefox
> version 100. Use this setting to test whether websites will break when
> Nightly hits a three-digit version number. The real Firefox 100 is scheduled
> to be released in May 2022, so start testing your websites now!
Firefox's User-Agent string says "Firefox/100.0" in both release and pre-release channels. Firefox 100's release date will be 2022-05-03. The Nightly 100 development cycle will begin 2022-03-08.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135316
The Nightly experiment's description:
> Firefox 100 User-Agent String
>
> Make Nightly send websites a User-Agent string that pretends to be Firefox
> version 100. Use this setting to test whether websites will break when
> Nightly hits a three-digit version number. The real Firefox 100 is scheduled
> to be released in May 2022, so start testing your websites now!
Firefox's User-Agent string says "Firefox/100.0" in both release and pre-release channels. Firefox 100's release date will be 2022-05-03. The Nightly 100 development cycle will begin 2022-03-08.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135316
The Nightly experiment's description:
> Firefox 100 User-Agent String
>
> Make Nightly send websites a User-Agent string that pretends to be Firefox
> version 100. Use this setting to test whether websites will break when
> Nightly hits a three-digit version number. The real Firefox 100 is scheduled
> to be released in May 2022, so start testing your websites now!
Firefox's User-Agent string says "Firefox/100.0" in both release and pre-release channels. Firefox 100's release date will be 2022-05-03. The Nightly 100 development cycle will begin 2022-03-08.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135316
This is required to replace the existing MOZ_FORCE_ENABLE_FISSION environment
variables in environments which use that. In the future we'll want to stop
passing any environment variable when not passing a flag to `./mach run`
however that will require changes to the default test behaviour in bug 1744091.
Differential Revision: https://phabricator.services.mozilla.com/D133006
None of this is used now that `funsize` generates update MARs. It
might have even been possible to remove this in Bug 1173459, years
ago.
Differential Revision: https://phabricator.services.mozilla.com/D132836
Paul Adenot
Stanca Serban
Dave Townsend
Sandor Molnar
Anna Yeddi
Noemi Erli
Marian-Vasile Laza
Eemeli Aro
Cristian Tuns
Alan
janvi01
Greg Stoll
Francesco Lodolo (:flod)
Nicolas Chevobbe
Iulian Moraru
Chris Martin
Sylvestre Ledru
Kirk Steuber
Jonathan Sudiaman
Norisz Fay
Soheil
Molly Howell
Emilio Cobos Álvarez
Butkovits Atila
alwu
Alexandre Lissy
James Teh
Sean Pedigo
Greg Tatum
ramya
Gijs Kruitbosch
az
Chris H-C
Dão Gottwald
Tom Schuster
Katherine Patenio
Cosmin Sabou
John Bieling
Niklas Baumgardner
criss
Dmitrij Feller
Eemeli Aro
Mike Conley
Nika Layzell
gliu20
Chris Peterson
Nick Alexander
Narcis Beleuzu
Tyler Kabaker
Jan-Ivar Bruaroey
emilymichaels
Rob Wu
Mike Kaply
Nico Grunbaum
Shane Caraveo
Luca Greco
Rashelle Hopkins