This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
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
