Move all of the overlay pieces into an include file except for the
DTD's that could not be put there. Inline the DTD's into the files
where they were used. Update comments in macWindow.inc.xul and browser.xul
to more accurately reflect the current state.
MozReview-Commit-ID: HZIeSf29Yl
This adds workarounds to ensure that messages passed from browser.js
to content.js in the context of certerror pages always contain a frameId
which can be used to identify the frame that is supposed to receive them.
This fix is really meant to be temporary until we come up with a good
replacement for chrome - content communication, which probably boils down
to finding a middle ground between nsAboutCapabilities, RemotePageManager and WebChannel.
I did not update communication for Captive Portal pages, since those require
one-way broadcasting from chrome to content, which is not supported in this model.
This is tracked in bug 1446319.
I did also not change the behavior of the "Go Back" button, which still navigates
away the top level page, because I consider changing that behavior out of scope
for this bug (and in my personal opinion we should not change the behavior).
MozReview-Commit-ID: GrM6PFys6Cu
Two fixes here:
updateAppearance really depends on the tabbrowser.xml updateVisibility(), so
make that dependency explicit and remove the event handling from tabbrowser.
After the previous patch, TabsInTitlebar.init() runs much earlier, which means
that the initialization check that bails out from update() is not taken. Turns
out that this is definitely not an edge case, and that tons of initialization
code all over gBrowser.onDOMContentLoaded call updateAppearance(true), causing
tons of extra invalidation and reflows that aren't really needed.
Ensure we only do the work once.
MozReview-Commit-ID: 2E9b12aBast
Not doing can it cause perf issues, but old Linux distros aren't really happy
about it, and they barf when the chromemargin is removed dynamically, so prevent
that happening by default.
Right now it happens on the resize we do right before loading the window, but
that will stop working after bug 1439875.
MozReview-Commit-ID: 1Rhaz07fHaY
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
This gives the chance to code that relies on setting the XUL window attributes
to run before we actually size the window.
This should prevent the resizing on OSX and fix some other untested stuff that
the first commit probably broke...
MozReview-Commit-ID: DhCWgmCppek
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
Move the main contents of editBookmarkOverlay.xul into an include file and
inline the DTD and CSS files where used. Convert several chrome tests to
browser tests since the preprocessor is hard to use within the testing
framework.
MozReview-Commit-ID: DpPBOpZSuBN
This adds workarounds to ensure that messages passed from browser.js
to content.js in the context of certerror pages always contain a frameId
which can be used to identify the frame that is supposed to receive them.
This fix is really meant to be temporary until we come up with a good
replacement for chrome - content communication, which probably boils down
to finding a middle ground between nsAboutCapabilities, RemotePageManager and WebChannel.
I did not update communication for Captive Portal pages, since those require
one-way broadcasting from chrome to content, which is not supported in this model.
This is tracked in bug 1446319.
I did also not change the behavior of the "Go Back" button, which still navigates
away the top level page, because I consider changing that behavior out of scope
for this bug (and in my personal opinion we should not change the behavior).
MozReview-Commit-ID: GrM6PFys6Cu
