The delete file menuitem in the downloads context menu no longer
removes the download list item on its own, so the test needs an
explicit cleanup callback to remove the download it creates.
Differential Revision: https://phabricator.services.mozilla.com/D136577
The "Go To Download Page" menuitem in the downloads panel context menu
currently is always visible, even if the download is missing referrer
info. A download source should ideally always have referrer info,
but it's worth having a fallback so user doesn't see failures.
This patch also adds hiding for the "Copy Location" menuitem in the
unlikely event that a download is lacking a source or the source is
somehow lacking a URL. It implements a test to confirm hiding works.
I checked other downloads panel context menu tests to make sure they
aren't broken by the menuitems potentially being hidden.
This shouldn't close Bug 1723712 since we should ensure all downloads
have referrer info. This is just a stopgap in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D136457
I felt somewhat disoriented in the code when ramping up on it, so I
started documenting it with JSDoc as way to better understand the code.
Differential Revision: https://phabricator.services.mozilla.com/D136020
These were all areas that were confusing me when I was onboarding on to
this code, so I tried to make the terminology less ambiguous and more
precise.
The default language is now the primary language.
UI is now appended to words that are dealing with DOM elements rather
than data stores.
Differential Revision: https://phabricator.services.mozilla.com/D136019
The test test_typing_and_reload() was failing, I believe because without waiting for target url in browserLoaded(), we would proceed on the about:blank load and the new interaction write would race the test.
Differential Revision: https://phabricator.services.mozilla.com/D136186
* Define urlbarMarginInline and urlbarSearchButtonWidth as CSS rather than preprocessor variables
* Replace the urlbarViewPadding, urlbarViewFaviconWidth and urlbarViewIconMarginEnd preprocessor variables with CSS vars.
* Remove %ifdefs around the license comment in these 2 files
* Update ambiguous/out-of-date comment in the skeleton UI code
Differential Revision: https://phabricator.services.mozilla.com/D135962
This patch contains a proposed approach for the longer term fix we agreed on (see Bug 1746841 comment 10 and comment 11) and replace the
mochitest-browser added in the other patch attached to this bug with an xpcshell test (which besides covering the same base scenario
that mochitest-browser was convering, it is also lighter and covers also other cases that were not explicitly covered yet).
- added also an image to the test extension to explicitly verify the image caching behavior is also covered and works as expected
- added a test case to verify that cache images aren't cleared when the addon is permanently installed and it is not starting for an upgrade/downgrade
Differential Revision: https://phabricator.services.mozilla.com/D134508
Make the width and font sizes match the spec. Clean up button sizing. Remove lots of
unnecessary font-size overrides. Fix the margin for large size icons. Fix
the test PERSONALIZED_CFR_MESSAGE doorhanger and update it with a large
size icon to make it possible to test and debug.
Differential Revision: https://phabricator.services.mozilla.com/D129281
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
