This patch adds a state to AppUpdater to represent when an internal error has occurred. It also adds the appropriate code to the Update UI to be able to handle this state, along with a panel in each UI and a string that can go in the panels to convey to the user that update has failed.
Ideally, it would be good if this message also directed the user to a SUMO article. See Bug 1787309 for details on this. But at the moment, I would prefer to address Bug 1756450 quickly rather than wait for that to be ready.
Differential Revision: https://phabricator.services.mozilla.com/D156998
MathML Core specifies that operators containing a UTF-16 strings whose
length is not 1 or 2 should use the default properties [1]. This
commit removes the obsolete strings of length 3 from our operator
dictionary and tweak updateOperatorDictionary.pl to ensure it only
accepts strings of 1 or 2 characters. This also adds an early return
in LookupOperator to immediately fallback to default properties.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
Differential Revision: https://phabricator.services.mozilla.com/D157706
With the addition of the Firefox View button/tabstrip, there is a new
tabstop that is present at the start of the TabsToolbar. When the
Firefox View button is not present, this new tabstop causes tab
navigation to skip over the selected tab and instead focus the new-tab
button. Then, when trying to navigate backwards from the selected tab,
this tabstop at the front of the TabsToolbar forces us to re-focus the
new-tab button. This is because the tabbrowser-arrowscrollbox-periphery
container has zero width/height which causes the tabstop inside of this
container to be skipped over, which then focuses the new-tab button
instead of the selected tab.
This patch allows zero width nodes to be skipped instead of rejected.
This allows the tabstop within the zero width periphery container to be
the first valid element when navigating forward from the tabstrip,
instead of the new-tab-button that is outside of the <tabs> element.
This restores the previous behavior of a selected tab being the first
focusable item when navigating forward from the end of web content, if
there are no items in the tabstrip.
Differential Revision: https://phabricator.services.mozilla.com/D157351
Only show the Firefox View tab in the Ctrl Tab panel if it's currently selected
(and the same for any other pages that can be simultaneously hidden and
selected, if any are added in the future).
Differential Revision: https://phabricator.services.mozilla.com/D157595
This is the last fix needed for this.
The issue is that command events now are triggered by synthetic click
events (which was not the case before pretty much by chance, a side
effect of how these events were implemented).
If we open a panel by a command event triggered by the synthetic click
event, rather than the real keypress event, we end up not detecting that
it is really a keyboard activation, and not focusing the first navigable
element in the panel for example, which is unfortunate.
This was caught by browser_toolbarButtonKeyPress.js.
We could keep the old behavior of not triggering commands from
dispatchEvent()-ed clicks, but honestly that's kind of bizarre.
Differential Revision: https://phabricator.services.mozilla.com/D157596
(To be landed right after the soft freeze is over)
One interesting consequence of my previous patch in this bug, is that
the time at which the XUL element processes the click event is different
(earlier, at bubbling phase rather than after everything).
This caused some test failures caused by the panel autohide, since now
it goes after than the native handling and the native handling
default-prevents to dispatch the XUL command.
Given we don't check key events for defaultPrevented either, it makes
sense to be consistent.
This uncovered an interesting failure, where the "show more tabs" button
in the sync menu starts closing the panel unexpectedly on click. The
right fix is to use closemenu="none" in that button, since otherwise
that button is not keyboard accessible (this is an issue on current
nightly that this patch fixes).
Differential Revision: https://phabricator.services.mozilla.com/D157584
Create XULButtonElement instead to do the event handling. Pretty much a
straight port, this allows these elements to respect CSS display
properly (and use modern flexbox rather than old XUL layout).
Differential Revision: https://phabricator.services.mozilla.com/D157509
This patch also adjusts some `min-width` rules like it was done for the
downloads button. It should work with either buttons OR both, which is
going to happen since the unified extensions button will be most likely
always visible in the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D154360
In the Page Info window, the "Select All" button and the "Save As..."
button directly next to it share the same access key (in English). This
is because the "Select All" button shares its strings with the "Select
All" menuitem. This patch just adds a new fluent string for the button
and changes the access keys so they don't overlap.
Differential Revision: https://phabricator.services.mozilla.com/D143666
Only the bytes of the failed certificate chain are used, so that's all we need
to send across, rather than the entire nsITransportSecurityInfo.
Differential Revision: https://phabricator.services.mozilla.com/D157007
The DevToolsSocketStatus could be misleading for any usage other than the current one from browser.js since it misses browser toolbox sockets
This patch allows the singleton to track all sockets but changes the API to allow consumers to exclude browser toolbox sockets.
Differential Revision: https://phabricator.services.mozilla.com/D157300
Non-MSIX notifications are not removed when Firefox is uninstalled. To handled this we've added a new `uninstall` background task and extended `nsIWindowsAlertService` to deregister notifications on uninstall.
Differential Revision: https://phabricator.services.mozilla.com/D156625
Most of the display: block stuff isn't needed anymore because we changed
the blockification behavior in bug 1789123.
.tab-stack, and stacks in general now uses CSS grid so doesn't need that
anymore.
DevTools is the only consumer of <xul:iframe> and width/height was
getting ignored in XUL because flexibility takes precedence, so just
remove the relevant declarations.
Differential Revision: https://phabricator.services.mozilla.com/D157070
Trivial test-case: data:text/html,<script>alert("foo")</script>
The dialog grows because of the grid container, and -moz-box prefers
honoring flexibility to the explicit height, so this declaration is
useless.
Emulated flexbox actually honors it and crops the dialog. Just remove
it.
Differential Revision: https://phabricator.services.mozilla.com/D157069
The synchronous DocumentL10n instance that's created here is not exposed on the root document, as that is the user-defined XML document. The localization root that's connected to it is in a closed shadow root.
This localization won't update on locale changes, but that matches what this view was previously doing.
Differential Revision: https://phabricator.services.mozilla.com/D156544
Make the dialog frame for Spotlight modal dialogs cover the full window,
prevent the fixed sizing in SubDialog for these dialogs, and vertically
center the dialog relative to its frame. Make the scrollport accommodate
the full Spotlight so it can be scrolled, without wasting any scroll
distance on margins. So, the top margin will shrink with the window,
like the other margins do.
Differential Revision: https://phabricator.services.mozilla.com/D156127
Make the dialog frame for Spotlight modal dialogs cover the full window,
prevent the fixed sizing in SubDialog for these dialogs, and vertically
center the dialog relative to its frame. Make the scrollport accommodate
the full Spotlight so it can be scrolled, without wasting any scroll
distance on margins. So, the top margin will shrink with the window,
like the other margins do.
Differential Revision: https://phabricator.services.mozilla.com/D156127
I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...
In any case while going through the code the status panel can be
simplified a bit now, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D156876
