This modernizes an old part of the build system to not require
build-time localization at all. That's generally preferable.
The most significant changes to the in-product functionality is to
make import localize HTML so that we can use Fluent's `data-l10n-id`.
The locale used is the user's current locale. This is different than
the existing approach, which always uses the build-time (repack)
locale. I believe this is a strictly superior user experience and it
may lead to future improvements where-in the default bookmarks become
truly dynamic and vary with the user's chosen locale rather than being
point-in-time decisions.
I tried to restrict these changes to only applen when we import the
default bookmarks, but I think the various layers of flags no longer
achieve this restriction in practice and the formatting and
localization will apply to all imported `bookmarks.html` files. Since
we don't anticipate (nor ourselves write) these new things in
(respectively, to) `bookmarks.html`, and the file is already
user-controlled, I don't think this exposes any meaningful change in
functionality (or in security surface).
Some notes:
1) There's no migration of `.inc` -> `.ftl` because this is the lone
`.inc` file.
2) I elected to prefix all strings with `default-bookmarks-`, since
the existing names were very short and likely to collide (now or in
the future).
3) I elected to change the HTML file name for easier searching.
4) Since the `default-bookmarks.html` file is product-specific and the
existing tests are in `toolkit/`, I elected to not test the file
directly in automation.
5) We removed the explicit locale (or equivalent `%LOCALE%`) since
Mozilla properties will redirect to the appropriate language
automatically.
Differential Revision: https://phabricator.services.mozilla.com/D135816
* Remove the whole browser/components/payments directory
* ..including the nsIPaymentUIService implementation and its component registration
* Update docs index to remove the web payments UI source docs
* Remove residual rules from browser CSS
* Remove references from the static analysis tests
Differential Revision: https://phabricator.services.mozilla.com/D127329
The reveal password button might or might not be web-compatible, but it
might be worth having a separate pref for the context-menu entry.
Depends on D136086
Differential Revision: https://phabricator.services.mozilla.com/D136087
The pseudo-class and nsContextMenu context attribute were using reveal,
the pseudo-element and webidl attribute were using "show".
Use reveal consistently and update the accesskey so that there aren't
conflicts with existing commands. Also enable the feature in
browser_contextmenu_input.js so that this change is tested.
Differential Revision: https://phabricator.services.mozilla.com/D136086
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
The edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
The edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
