This is also gone from the parent process because previously it was forced to be early loaded by the fact that process-content.js also runs in the parent. Now the parent side is first initialized by the Cu.import from the Activity Stream code, which is later in the startup process
MozReview-Commit-ID: FEypEi0Eemc
--HG--
extra : rebase_source : 6a682dff38370410c91cac44f1f5b2739f0247d1
`errorMessage` only contains 'TypeError: docShell is null' whereas `message` contains the file path and line.
MozReview-Commit-ID: 7Tuqph1b3lV
--HG--
extra : rebase_source : fdf20be275adaac41f25ebeee67d142456f4da8b
This is easier to understand as we don't have to round-trip the whole success and error states to the privileged wrapper which could potentially lead to stale state changes.
This is also much simpler for the basic-card-form as it doesn't need a lot of the complexity of the previous implementation.
* Move selectedStateKey from page to address-page since it doesn't apply to basic-card-page
MozReview-Commit-ID: B4kiZNWElGI
--HG--
extra : rebase_source : bcca13bbdc506961834e2e3cc078dad7d6ee7ca7
* Provide an cc-exp-year option to match cc-exp-month
* Make cc-number and cc-name required in the basic-card-form
* Disable the basic-card-page save button when the form is invalid.
MozReview-Commit-ID: LjzsnAKJp6R
--HG--
extra : rebase_source : 4dcbee371cd0e30b5823b803c4f4734f897ec786
This goes back to relying on rows being the same height.
Places where we replace the popup will likely not use the richlistbox,
and we no longer have code that changes the height or exceeds the maximum
number of visible children with a scrollbar, so we should be OK.
To determine the padding on the richlistbox and the height of the initial
row, I've used a promiseDocumentFlushed callback. It's possible this causes
flicker the first time the popup opens. I can't see any, but it's quite
possible I'm missing something.
Differential Revision: https://phabricator.services.mozilla.com/D2242
--HG--
extra : moz-landing-system : lando
This is easier to understand as we don't have to round-trip the whole success and error states to the privileged wrapper which could potentially lead to stale state changes.
This is also much simpler for the basic-card-form as it doesn't need a lot of the complexity of the previous implementation.
* Move selectedStateKey from page to address-page since it doesn't apply to basic-card-page
MozReview-Commit-ID: B4kiZNWElGI
--HG--
extra : rebase_source : 183a3bd44ed33566fccdc024eabdccef83554d50
* Provide an cc-exp-year option to match cc-exp-month
* Make cc-number and cc-name required in the basic-card-form
* Disable the basic-card-page save button when the form is invalid.
MozReview-Commit-ID: LjzsnAKJp6R
--HG--
extra : rebase_source : 467fa09ea07c0234e1839b6dfd7e53375c118104
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
This is a small performance optimization for callers of willOverrideHomepage.
They want to know if the URL the window was passed will be overridden. Once
we finish restoring windows, that'll never happen again, and we can return
without waiting for a promise.
MozReview-Commit-ID: NhKDHT6rBX
--HG--
extra : rebase_source : a88b625f13516b630f68a752577ef89e829b7bd4