The tab context menu is designed to not be translated until the user
interacts with the tab strip in some way. However, the tab context menu
is now shared between the tab strip and the "all tabs" panel. So, it's
possible to open the tab context menu without interacting with the tab
strip. This results in the context menu being opened before it is
translated, so the user sees an essentially blank menu. Resolve this
by adding to the all tabs panel an extra initialization step that will
automatically translate the tab context menu.
Differential Revision: https://phabricator.services.mozilla.com/D142850
This should mostly avoid the issue where newly created pinned tabs when
restoring a session are first created in the shared web process, and
migrated into the correct process upon navigating. I also added
remoteType prediction to the undoCloseTab and duplicateTab codepaths
to avoid unnecessary process changes there as well.
Differential Revision: https://phabricator.services.mozilla.com/D141146
This should mostly avoid the issue where newly created pinned tabs when
restoring a session are first created in the shared web process, and
migrated into the correct process upon navigating. I also added
remoteType prediction to the undoCloseTab and duplicateTab codepaths
to avoid unnecessary process changes there as well.
Differential Revision: https://phabricator.services.mozilla.com/D141146
Blaming this code goes all the way through interesting history. This
code was originally made conditional in bug 1379587. At that time, the
use_system_colors pref wasn't true on Windows by default (it is now).
I think we only really want to do this if we're forcing content colors.
Otherwise we really want to match the new tab page colors, and the
use_system_colors pref doesn't change that.
The code in the condition is not perfect, mind you. In particular, it
should deal with document_color_use = 1 + high contrast theme, plus the
canvas color should react to the content color-scheme, not the browser
color-scheme. I thought of how to best fix that, and I think probably a
new system color for chrome to expose this makes sense, or alternatively
a ChromeUtils API or something, because otherwise reverse-engineering
everything that goes on in layout/style/PreferenceSheet.cpp is going to
be a huge mess.
But I'd rather do that in a follow-up bug, since it's nothing new and
this should fix Windows' default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D137377
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
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
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
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
