I copied the browser.js contents to browser-siteIdentity.js, there are no changes.
MozReview-Commit-ID: AytWG2oijXc
--HG--
extra : rebase_source : 17e69c8aa92eeae866fc76d3669d3b551592f755
Tests are also added here for the legacy `getTopWindow` method to guard against
basic regressions.
We now start tracking browser windows right after the DOMContentLoaded event, which
is earlier than before. We now also assume that any newly tracked window has the
focus initially, which is closer to the nsIWindowMediator semantics.
MozReview-Commit-ID: 6QYJqA1tMPC
--HG--
extra : rebase_source : e04e567cf31d1a10e78647d75403b700bc65136b
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
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
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
--HG--
rename : browser/base/content/macBrowserOverlay.xul => browser/base/content/macWindow.inc.xul
extra : rebase_source : 5772943e01b4c6de7526ab829c6ea5b6960016e5
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
--HG--
extra : rebase_source : 135cd9abe570736b80587a018ba5caba59247e10
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
--HG--
extra : rebase_source : 253bea4c4e90727c0e8cce4726bf7a695ca26d9d
extra : source : 4d6f855ea529f6043b3ca886f53901e16a3d6405
extra : histedit_source : b0aa76063dca7a85e43b3bf670aab8f185a57915%2C760885a660c4fd92e7ae777614ad3cdc84dc9b31
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
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
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
--HG--
rename : browser/components/places/content/editBookmarkOverlay.js => browser/components/places/content/editBookmark.js
rename : browser/components/places/content/editBookmarkOverlay.xul => browser/components/places/content/editBookmarkPanel.inc.xul
rename : browser/components/places/tests/chrome/test_bug427633_no_newfolder_if_noip.xul => browser/components/places/tests/browser/browser_bug427633_no_newfolder_if_noip.js
rename : browser/components/places/tests/chrome/test_bug485100-change-case-loses-tag.xul => browser/components/places/tests/browser/browser_bug485100-change-case-loses-tag.js
rename : browser/components/places/tests/chrome/test_bug631374_tags_selector_scroll.xul => browser/components/places/tests/browser/browser_bug631374_tags_selector_scroll.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_keywords.xul => browser/components/places/tests/browser/browser_editBookmark_keywords.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_tags_liveUpdate.xul => browser/components/places/tests/browser/browser_editBookmark_tags_liveUpdate.js
rename : browser/themes/linux/places/editBookmarkOverlay.css => browser/themes/linux/places/editBookmark.css
rename : browser/themes/osx/places/editBookmarkOverlay.css => browser/themes/osx/places/editBookmark.css
rename : browser/themes/windows/places/editBookmarkOverlay.css => browser/themes/windows/places/editBookmark.css
extra : rebase_source : aca072691251c1a44e82ab8091796abd2b140e22
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
--HG--
extra : rebase_source : 5a49571b04b682bcde61e61f9874a25e405661f5
textContent is used to set the indicator label text here instead of the value attribute because the text set using the value attribute does not wrap when it exceeds the width of the panel, which in turn pushes the menulist and half of the indicator text out of view.
MozReview-Commit-ID: 1VBaQlbZwzQ
--HG--
extra : rebase_source : 9bda7f5d8ec59b61dbc0e93c9a715c971ab5dceb
This resolves some confusion around the required callback for
`openInExtenalEditor` by converting it to instead return a Promise. This also
simplifies the flow of its callers as well.
MozReview-Commit-ID: EYoucELJLbu
--HG--
extra : rebase_source : b27541f6d86b06d967b6a5023d82c43efb422d67
