It does the same as window.devicePixelRatio. However a bunch of this
code is copy-pasted code trying to scale a canvas, but not messing with
full zoom is the right thing to do.
The full zoom value in the top level browser.xhtml page is always 1
anyways, and WindowsPreviewPerTab looking at the current browser tab's
full zoom is just bizarre...
Differential Revision: https://phabricator.services.mozilla.com/D138020
screenForRect takes screen coordinates (device pixels, for our purpose here).
However screenX / screenY are in CSS pixels, so we need to convert them to the
right coordinate space before looking up the screen.
Differential Revision: https://phabricator.services.mozilla.com/D137895
* I overlooked that some `window.open` feature names are different from
barprop names.
* Adding "resizable" will regress the maximize button prblem. But it was
broken even before bug 1564738 and fixing it requires changes to session
data. The current session data do not contain enough information to restore
the maximize button state correctly. I'll file a follow-up bug about this.
* I renamed the test file because it is no longer limited to tab visibility.
Differential Revision: https://phabricator.services.mozilla.com/D137838
The code for rendering these is better than for <xul:image>. Remove
validate="never" because it'd do nothing with HTML images and we don't
need this (favicons are data: URIs so they are always cached / never
revalidated).
Differential Revision: https://phabricator.services.mozilla.com/D137746
The test browser_bug906190.js will trigger the dFPI heuristic that will
create an unnecessary 3rd party cookie permission and it may affect
following tests. So, we disable the dFPI heuristic in the test,
then the heuristic won't be triggered.
Differential Revision: https://phabricator.services.mozilla.com/D137754
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
