The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
The devtools theme is no longer relevant when dealing with compact themes, since it doesn't
affect the theme colors. But we still need it for styling other things related to devtools
in browser.xul, like the splitter between the toolbox and page and gcli.
MozReview-Commit-ID: 2CXDuwQY19x
This commit does the following:
* Install two lightweight themes instead of one
* Introduce a build config to install the themes instead of relying on channel: INSTALL_COMPACT_THEMES
* Change browser-compacttheme to use the new themes instead of the old one
* Remove inferBrightness since the lwt colors are part of the compact theme definision, as opposed
to the devedition theme which could be light or
* Update CSS to use :-moz-lwtheme-darktext and :-moz-lwtheme-brighttext instead of [devtoolstheme]
MozReview-Commit-ID: 4gKU68drlE2
We won't need this anymore, since there will be a separate light and dark theme
definition, so we can update the theme definition to allow the brightness to be
inferred automatically by the lightweight theming system.
MozReview-Commit-ID: 3GuZ3Qezc1F
This is kind of a sad story. In bug 1254669, I made it so that we destroy the original
tab progress listener and create a new one when flipping remoteness. This is because
the initial about:blank load for a flipped browser is not something we ever want
to show progress for.
I goofed though*, and didn't call the mTabProgressListener constructor with the right
argument that indicates that the first messages are from about:blank. This opened us
up for a race with e10s-mode where, after a tab tear out, the initial browser would
flip remoteness to remote, send up a StateChange message to indicate loading of
about:blank (which we'd accidentally listen to). The race happened when we'd sometimes
do the frameloader swap before the StateChange to indicate that about:blank had finished
loading would come up. This would mean (after the frameloader swap), we'd never hear
about the initial about:blank finishing loading, so we'd always show "busy".
* :(
MozReview-Commit-ID: 6pU1fqiIDUc
