I came across this again when trying to address bug 1756676 and figured
I would just address this bug immediately per our previous discussion
on the bug.
Differential Revision: https://phabricator.services.mozilla.com/D139421
The root cause of the bug is fixed by the previous patch. This patch improves
the calculations to work properly across mixed dpi displays (which doesn't work
on release either by any stretch).
Hopefully it's somewhat straight-forward to follow.
Depends on D139243
Differential Revision: https://phabricator.services.mozilla.com/D139244
And cleanup similar code in nsXULTooltipListener. That code shouldn't
need to deal with zoom since the target and the tooltip are in the same
document.
Differential Revision: https://phabricator.services.mozilla.com/D139235
* Remove the contents of the browser/components/payments directory
* Excepting the nsIPaymentUIService implementation and its component registration - to allow the /feature-policy/payment-allowed-by-feature-policy* tests to continue to run and pass
* 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
Note that it's not 100% clear whether this bug is responsible for the
improvement or not, but given it's an improvement...
MANUAL PUSH: Unexpected pass CLOSED TREE
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138036
Differential Revision: https://phabricator.services.mozilla.com/D138037
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
If the page is zoomed, its devicePixelRatio will differ from the browser
chrome's. Account for this by converting to device pixels before starting to
scroll.
Depends on D138036
Differential Revision: https://phabricator.services.mozilla.com/D138037
Users may map reserved shortcut keys of Firefox/Thunderbird as an editing
command or a navigation command. Therefore if and only if an editable element
has focus and a reserved key combination is mapped to an editing command or
a navigation command by the system settings, we should allow to dispatch it
into the content and work it as what user expects.
With this change, keyboard only users may loose some shortcut keys to leave
from a web content which blocks keyboard focus in it. However, there may
be another reserved shortcut keys to escape from such web apps only with
keyboard because it's hard to think that all reserved shortcut keys conflict
with users' settings.
Differential Revision: https://phabricator.services.mozilla.com/D138009
The All Tabs Menu tries to scroll the selected tab element into view
when the All Tabs view is shown. But depending on user prefs, pinned
tabs are elided from the menu, resulting in no selected tab element.
So this can invoke undefined.scrollIntoView and result in an error.
Differential Revision: https://phabricator.services.mozilla.com/D137514
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
* 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