The regressing bug (bug 1448286) removed a redundant call to
gBrowser.tabContainer.updateVisibility. It appears that removed call was
necessary for restoring the tabbar of windows that were originally opened as
dialogs.
In D53692, we tried to avoid the extra cost of removing and readding the tab if
we were restoring a single-tabbed window, but it turns out that it's required to
get around the above.
Differential Revision: https://phabricator.services.mozilla.com/D124358
The regressing bug (bug 1448286) removed a redundant call to
gBrowser.tabContainer.updateVisibility. It appears that removed call was
necessary for restoring the tabbar of windows that were originally opened as
dialogs.
In D53692, we tried to avoid the extra cost of removing and readding the tab if
we were restoring a single-tabbed window, but it turns out that it's required to
get around the above.
Differential Revision: https://phabricator.services.mozilla.com/D124358
We pass 8.3 names to NSS to avoid non-ASCII characters because NSS still
depends on the system code page (although this workaround is not effective on
East-Asian locales).
We don't have to use 8.3 names to NSS for SQLite db paths because SQLite
always use UTF-8 for file names.
Differential Revision: https://phabricator.services.mozilla.com/D137379
We are fixing mochitests that fail when network.cookie.cookieBehavior = 5, i.e. when we enable Total Cookie Protection.
This is most often due to the test assuming that an origin will always have access to its storage state when embedded as
a third party.
My approach: Add third-party storage permission to the favicon's origin (http://example.com) for each test.
The feature tested here assumes third-party storage, so we have to give it to expose the code paths being tested.
In this case, those paths are to send cookies with a favicon request when `crossorigin="use-credentials"` in the favicon's link tag.
Differential Revision: https://phabricator.services.mozilla.com/D136600
Whether the overflow happens intentionally or not, it wasn't caused by
the regressing patch so I think we should probably just do this for now.
Differential Revision: https://phabricator.services.mozilla.com/D137289
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
I've erred on the side of removing code here. I think that I got most of it,
but there was quite a bit of accrued code.
Thanks to Gijs for fluent fixups (and code cleanup). This retains some notice
of the failed version.
Bug 1586846, Bug 1579285, Bug 1586846, and Bug 1617275 all added code here.
Differential Revision: https://phabricator.services.mozilla.com/D133591
Add a PlacesPReviews.jsm module that offers an alternative long term storage of
thumbnails or images. Previews are stored using md5 hash of the page url, in WebP format.
Removals happen using the moz_previews_tombstones table, orphans removal happens
on Places weekly maintenance.
The same moz-page-thumb: protocol that is currently used for volatile thumbnails,
can be used with Places previews, by using "places-previews" as host.
All the feature is behind the places.previews.enabled pref, not enabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D131916
Add a PlacesPReviews.jsm module that offers an alternative long term storage of
thumbnails or images. Previews are stored using md5 hash of the page url, in WebP format.
Removals happen using the moz_previews_tombstones table, orphans removal happens
on Places weekly maintenance.
The same moz-page-thumb: protocol that is currently used for volatile thumbnails,
can be used with Places previews, by using "places-previews" as host.
All the feature is behind the places.previews.enabled pref, not enabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D131916
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
Instead of showing:
(pid 3) [F 2, 1, 4]
The tab tooltip will now show a combined list of pids with the content pid followed by a sorted list of subframe pids:
(pids 3, 1, 2, 4)
Depends on D133854
Differential Revision: https://phabricator.services.mozilla.com/D133855
The behaviour that this test is testing is specific to the old UI. The new UI
allows users to switch tabs at will while tab modal print previews are open.
Differential Revision: https://phabricator.services.mozilla.com/D133432
We're already batching similar styles, so by using classes instead of
style attributes and :nth-child selectors we allow the elements to share
styles, and make their styling more efficient over-all.
Differential Revision: https://phabricator.services.mozilla.com/D132829
Remove start screen reusing its subtitle on the colorway screen. Get the previous theme before ready as colorway screen is now first and randomly picks a color, so detect testing to remove randomness. Show rounded mostly transparent background for variants now packed more tightly within the disc. Shrink and deemphasize secondary button. Reenable upgrade spotlight after turning off in D131023.
https://www.figma.com/file/blhdnzQOhWYKcdiCzywMuG/MR2-Onboarding?node-id=2548%3A158106
Differential Revision: https://phabricator.services.mozilla.com/D130930
To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.
On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.
Differential Revision: https://phabricator.services.mozilla.com/D128681
#overrideWeakCryptoPanel was removed in bug 1321778, so the CSS is dead and I removed it.
Otherwise I'm dragging the 2 advanced panel bits into using .hidden instead of
inline CSS, and using the single 'advanced-panel' class to handle more of their styling,
with the box background/border moving to an ID selector to keep it specific to the
bad cert bits.
Differential Revision: https://phabricator.services.mozilla.com/D129027
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
Make `chrome/browser/content/browser/license.html` include the
WinToast license if the WDBA is enabled and never include the WinToast
license in `chrome/toolkit/content/global/license.html`.
While here, fix the anchor, which is case sensitive.
Differential Revision: https://phabricator.services.mozilla.com/D132421
"Send Video to Device" feature is gone in desktop and mobile, and also,
we removed Presentation API implementation, so this is unnecessary now.
Differential Revision: https://phabricator.services.mozilla.com/D132330
CLOSED TREE
Backed out changeset a9e341a38fae (bug 1742582)
Backed out changeset a9ba4a859295 (bug 1742582)
Backed out changeset bd9307118864 (bug 1742582)
This commit does a couple of things:
- move whereToOpenLink and getRootEvent implementations into BrowserUtils,
so they can be used from the child process.
- forward callers in utilityOverlay.js to the BrowserUtils ones
(bug 1742889 will get rid of the forwarding and update all the callers;
we might be able to get this and bug 1739929 into beta if risk is low
enough, and touching a bunch of extra files really doesn't help with
that)
- move the lazy-load of BrowserUtils from browser.js to utilityOverlay.js
This is safe because everywhere that loads browser.js also loads
utilityOverlay.js. It's needed because there are some places that use
utilityOverlay.js but not browser.js, and so now they need access to
BrowserUtils.jsm.
- use whereToOpenLink to determine if we should avoid consuming the transient
user gesture activation in the child click handling code.
- add an automated test based on the testcase in the bug.
When working on this, I initially put the check using whereToOpenLink in
the toplevel of the function, and then when I ran places test to check that
I hadn't broken any places consumers of whereToOpenLink or getRootEvent,
realized that I had broken `browser_markPageAsFollowedLink.js`, because it
relies on "normal" (ie no modifier key, left button) link clicks making it
to ClickHandlerParent.jsm . I filed bug 1742894 about this. I've not tried
to fix that here, instead I've tried to ensure that paths through this
function are as untouched as possible while still fixing bug 1739929 and
bug 1742801.
Differential Revision: https://phabricator.services.mozilla.com/D132102
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
- Adding browser tests to verify correct behavior in integration
- New test that fails on previous version: toolkit/components/antitracking/test/browser/browser_storageAccessScopeSameSiteWrite.js
- Add the ability to store permission by site, use 3rdPartyStorage for this
- No change is made to permission reads. These already proceed recursively, which eventually reach the site.
- When fetching all permissions for a principal, also look for site-scoped permissions on its site's principal
Differential Revision: https://phabricator.services.mozilla.com/D130675
Use Extension:FlushJarCache listener in ExtensionProcessScript.jsm instead,
it's already loaded everywhere and early enough from AddonManager.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D129952
It might fire before styles are invalidated, so it might cache the wrong
styles.
Instead, fire an event on the window once everything in that window has
been invalidated, not just the global theme.
This is causing failures with the patch in bug 1740089, since after that
patch `browser_ext_browserAction_theme_icons` trigger the theme changes
when switching from dark to default mode or similar.
Differential Revision: https://phabricator.services.mozilla.com/D131396
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163
Annotating each test individually lets us avoid introducing new failing tests
while we go through the backlog of failing tests.
Depends on D129162
Differential Revision: https://phabricator.services.mozilla.com/D129163