* 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
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
* 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 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
* 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
