With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
This adds preview localizations for remaining Firefox Suggest strings.
I removed support for `payload.helpTitle` and `sponsoredText`. The `helpTitle`
code comment says it's useful for experiments with hardcoded strings, but we're
not shipping experiments as extensions anymore, and in-tree experimental/
in-development features should use preview localizations AFAICT.
Covered by existing tests:
* browser/components/urlbar/tests/browser/browser_helpUrl.js
* browser/components/urlbar/tests/browser/browser_quickSuggest*
* browser/components/preferences/tests/browser_searchQuickSuggest.js
Depends on D122550
Differential Revision: https://phabricator.services.mozilla.com/D123032
This involves changing moveToAnchor to be allowed while the popup is showing. This change allows the buttons within the tab to use the normal algorithm for determining the tooltip position. This also fixes bug 1695900 so that tooltips for items in bookmarks menus also appear offset as well. Only the main tab and bookmarks on the toolbar appear aligned with the button's bottom edge.
Differential Revision: https://phabricator.services.mozilla.com/D115558
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
Share the concept of a panel content with all other menupopups / panels.
This avoids importing global.css in the shadow tree, and renames the
arrowcontent part to just "content", since we want to introduce a
"content" part for other panels.
This shouldn't change behavior but makes bug 1708136 a matter of
tweaking a couple CSS rules and fixing up test failures.
Differential Revision: https://phabricator.services.mozilla.com/D113990
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
To resolve this bug, we need page action icons and semantic page action nodes to be separate. That way, we can apply filters to the icons without also filtering the nodes' outlines. This means the semantic meaning of the page action button must move up a level, to the enclosing hbox. This means reverting bug 1482025, so I'd like a11y review on this patch.
Differential Revision: https://phabricator.services.mozilla.com/D114131
Depends on D114970
With this change, the title text of the robot icon now reads "Browser is under remote control by { $component }"
With component being one of DevTools, Marionette or RemoteAgent.
Note that if several components are listening at the same time, only the first one we checked is displayed.
Having several remote control tools running at the same time is considered as an edge case here.
The main goal of the feature is to help users identify what triggered remote control in case they are confused by the icon showing up.
Differential Revision: https://phabricator.services.mozilla.com/D115195
* Replace the many-shapes icon with a new simple download icon svg and update its consumers
* New start and finish animations using svg filmstrip images
* Toolbarbutton progress "bar" is a pie-chart, using a conic-gradient and a variable updated from js
* Show toolbarbutton animations even when download panel is open
Differential Revision: https://phabricator.services.mozilla.com/D113204
* Updates the addressbar "lock" icon for the tracking-protection blocked/disabled state, the default "no trackers" state, and the "trackers blocked" state. Where we used to animate the transition to trackers blocked, its now a static iconwith the same blue/purple gradient fill.
* Remove browser_protectionsUI_animation.js which was specifically testing the animation behavior and use of the animation frames as visible icons, which is no longer the case
* Rename and adjust browser_protectionsUI_animation_2.js which is primarily testing the active/not state of the icon
Differential Revision: https://phabricator.services.mozilla.com/D111507
Updates the addressbar "lock" icon for the tracking-protection blocked/disabled state, the default "no trackers" state, and the "trackers blocked" state. Where we used to animate the transition to trackers blocked, its now a static iconwith the same blue/purple gradient fill.
Differential Revision: https://phabricator.services.mozilla.com/D111507
