This trivially reproduces with ui.textScaleFactor=150 or so.
This needs to match ImageDocument::GetZoomLevel, for the math here to
work out.
Differential Revision: https://phabricator.services.mozilla.com/D174367
This trivially reproduces with ui.textScaleFactor=150 or so.
This needs to match ImageDocument::GetZoomLevel, for the math here to
work out.
Differential Revision: https://phabricator.services.mozilla.com/D174367
This trivially reproduces with ui.textScaleFactor=150 or so.
This needs to match ImageDocument::GetZoomLevel, for the math here to
work out.
Differential Revision: https://phabricator.services.mozilla.com/D174367
A workaround to provide opportunity to clear the `<input type=date>`, `<input type=time>`, and `<input type=datetime-local>` while an on-screen button option is being discussed.
Differential Revision: https://phabricator.services.mozilla.com/D167875
Resolving a regression caused by the bug 1676068 where NumLock state is inverted for `<input type=date>`, `<input type=time>`, and `<input type=datetime-local>` input boxes.
The code removed was introduced as a remediation to the bug 1314544 with the `keyCode` attribute used which was since deprecated.
Differential Revision: https://phabricator.services.mozilla.com/D164515
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:
- 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:
- 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:
- 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
This change prevents saving values from autocomplete="one-time-code" fields in form history as they just add noise and usually aren't useful.
Signed-off-by: Divyanshu Agrawal <agrawal-d@outlook.com>
Differential Revision: https://phabricator.services.mozilla.com/D158911
This helps avoid intermittent test failures that otherwise might happen if a
"font-info-updated" notification arrives partway through a test and causes an
unexpected restyle & reframe.
Differential Revision: https://phabricator.services.mozilla.com/D155156
Before D99291 the initialization was always done via SetSelectionRange because IsDirty was always true after input construction (because SetValue always set the flag regardless of whether actual change happened). Now the flag is always false initially, so we need to explicitly initialize the editor.
Differential Revision: https://phabricator.services.mozilla.com/D154995
By making image loading in <embed> and <object> behave more like when
an <iframe> loads an image, we can make sure that the synthetic
document generated is process switched if the image is cross
origin. This is done by making image loading in nsObjectLoadingContent
follow the document loading path.
We also make sure that we pass the image size back to the embedder
element to not get stuck with the intrinsic size.
To avoid named targeting being able to target these synthetic
documents, as well as showing up in `Window.frames` and being counted
in `Window.length`, we keep a filtered list of non-synthetic browsing
contexts for that use-case.
This feature is controlled by two prefs:
* browser.opaqueResponseBlocking.syntheticBrowsingContext
This triggers the creation of synthetic documents for images loaded
in <object> or embed.
* browser.opaqueResponseBlocking.syntheticBrowsingContext.filter
This turns on the filtering of synthetic browsing contexts in named
targeting, `Window.length` and `Window.frames`.
Differential Revision: https://phabricator.services.mozilla.com/D148117
Emilio Cobos Álvarez
Noemi Erli
Cristian Tuns
Makoto Kato
Kershaw Chang
Marian-Vasile Laza
Joel Maher
Anna Yeddi
Gijs Kruitbosch
Adam Vandolder
Butkovits Atila
Sandor Molnar
Tom Schuster
Divyanshu Agrawal
Edgar Chen
Sean Feng
Norisz Fay
Narcis Beleuzu
Mathew Hodson
criss
a153
Mark Banner
Daniel Holbert
Kagami Sascha Rosylight
Andreas Farre
Tooru Fujisawa