This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
The overlay was responsible for script loading and defining three elements
(bhTooltip, placesCommands, placesContext). In the majority of places where
the overlay was included only part of it was used. To remove the overlay, the
elements were each split into include files and moved into where they
were used. For the scripts, a JS file was added that defines all the lazy
modules and then this script, globalOverlay.js and utilityOverlay.js were
inlined to everywhere that would have included them from the overlay.
MozReview-Commit-ID: 8T5D46oYWLn
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
This adds support for download progress reporting via the XApp
method currently used in the Cinnamon desktop, by establishing a new
X11 window property to be supported/read by the window manager.
See https://github.com/linuxmint/xapps/blob/master/libxapp/xapp-gtk-window.c,
as well as https://github.com/linuxmint/muffin/commit/39045da0ea06f
for more details.
The property-setting code lives in nsWindow - it's a small and stable
enough chunk that it made more sense to do this than actually depend on
another external library. As nsWindow is already using x11 calls, this
seemed the safest place for it, without affecting the build.
The TaskbarProgress instance is initialized via the DownloadsTaskbar
js module, and is handed a pointer to the current main window to call
SetProgress on. Most of the javascript side of this is in line with
how the other platforms are handled.
Without a supporting window manager/desktop environment (currently just
Cinnamon/Muffin 3.6,) the simplest way to observe working behavior is
by calling 'xprop -spy' on the browser window being testing and watching
for updates during a download.
Regression from bug 1398713. Before that, we reloaded the entire webext-panel.xul if the
sidebar changed. This verifies we don't reload unecessarily as well as discards
the browser to force a runtime disconnect for the extension if it does change.
MozReview-Commit-ID: LuYxmj9mSb7
There are 3 issues here:
- the runtime changing of the title causes issues where the content title is
not set. This is fixed by setting it to the private title by default;
there is very little (if any) UI that allows users to even open
about:privatebrowsing in 'normal' windows so we care a lot less about
flicker there. To be able to include this title in the markup, we switched
to a dtd.
- the 'empty tab' title we set on the tab initially is set when the tab is
created. This has been updated to check for private windows, and default to
'Private Browsing' instead. This will obviously also affect other new tabs
in private browsing, but that seems desirable/consistent.
- Likewise, we use this title when updating a tab's title that we don't yet
have a content title for (which can still happen while about:privatebrowsing
is loading because e10s), and so that is updated, too.
MozReview-Commit-ID: nVfXD2M6UZ
