The original name of the profile is irrelevant here since we aren't testing
a migration to profiles-per-install. On dev-edition DEDICATED_NAME is the same
as PROFILE_DEFAULT so we correctly make a new profile with a unique name.
Differential Revision: https://phabricator.services.mozilla.com/D26230
--HG--
extra : moz-landing-system : lando
This fixes two bugs. The first is that when the firefox profile migrator doesn't
know which profile to migrate it attempts to fall back to another profile. I
think this was intended to be the default but in bug 1322797 I ended up making
it the current profile, which is the profile we're restoring into now. I think
at this stage the profile directory doesn't even exist so things go wrong.
Changing to use the actual default works but....
When the profile migrator UI doesn't know what profile to migrate from it uses
the default profile. So if the profile you're actually trying to restore is not
the default we'll effectively throw its data into the archive and replace it
with data from the default profile. I'm inclined to say that if the migrator
does not know what profile to migrate from it should error at that point for
safety.
Why would the profile migrator not know what profile to migrate from? Because of
a long-standing text encoding problem. In C++ profile names are encoded in UTF8.
But we try to pass them to JS through an IDL parameter of type ACString. This
does no UTF8 decoding and so JS recieves an incorrect name if the name includes
non-ascii characters and so can't find the profile.
This patch fixes the IDL parameter to AUTF8String which does the decoding
correctly and so JS gets the name correctly.
We should probably think about whether just passing the nsIToolkitProfile object
to the migrator is a better choice here.
Differential Revision: https://phabricator.services.mozilla.com/D26250
--HG--
extra : moz-landing-system : lando
This fixes the filename and line number of login manager logs.
This is basically a rebased backout of the LMH portion of changeset b1e3cd7db269.
Differential Revision: https://phabricator.services.mozilla.com/D26023
--HG--
extra : moz-landing-system : lando
Since we rarely touch this code, I took the liberty of changing this to a JS class
and fix the contrast ratio calculations to actually conform to the WCAG spec,
instead of using arbitrary constants.
I changed the `isBright` getter to `useBrightText`, because that is more apt;
we're usually looking for an answer to 'should I use white text on this background?',
instead of looking for an arbitrary threshold to classify a color as being bright.
I updated the tests to cover more of this and clarified the assertion messages as
well.
Differential Revision: https://phabricator.services.mozilla.com/D26097
--HG--
extra : moz-landing-system : lando
The Prio pilot project has completed, so we no longer need to add prio-encoded
payloads to the "main" ping.
Differential Revision: https://phabricator.services.mozilla.com/D26004
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
Changing RemoteWebProgress to a C++ XPCOM object will cause the request being
passed into the `onStateChange` handler in `promiseBrowserLoaded` to become a
wrapped XPCOM object for an nsIRequest, instead of the JS object it was
previously. This results in the attribute lookup for `originalURI` on the
request to fail, leading to cascading failures.
Differential Revision: https://phabricator.services.mozilla.com/D24809
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
Some sites use `email`, `tel` and `tel-national` values for @autocomplete even when they are used as the username and 'username' would be more appropriate.
We already allowed type=email / type=tel so allowing the autocomplete equivalents is reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D25883
--HG--
extra : moz-landing-system : lando
