Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that case open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.
Also includes the patch from bug 1523725.
--HG--
rename : browser/themes/shared/information.svg => toolkit/themes/shared/profile/information.svg
extra : rebase_source : 3bf8b329eb5ea9e71fe2f0ed34a7e44dfdc434fd
extra : intermediate-source : 21a801ca5f6d435509f93e1dee187cb6ca868c8f
extra : source : c9d89812bc226ca593119bf440cb4f5e50ac2ace
On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : 1505cf27f900070debc1f9e1c71ec4bef3bc099d
extra : source : 05200c5388b4f7adc4414268727458515d7b9ed9
Set a telemetry scalar depending on the path taken during profile selection at
startup.
Differential Revision: https://phabricator.services.mozilla.com/D17696
--HG--
extra : rebase_source : bb4056c1c234f3aa61aedc8fddc87193f7aa45a9
extra : source : ebcd8225434ae82b837d632b5ef44bcc9dd5c5b0
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : 0250c70e992fd8369e52ccee3755cf116a894791
extra : intermediate-source : e69cac07b209ad4ef4229815ffd8138ed64c348e
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : cefe252618cd3a1b0e0cd5a71b056dd2b557f1a3
extra : intermediate-source : 35af79575f54f75d22e213fdac7ddd704b40807a
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
Send a downgrade ping to telemetry when the downgrade UI is displayed.
--HG--
extra : rebase_source : 799ef400bc20aaab520641d21d744fe83aa5da27
extra : intermediate-source : 6bb1233693b8b2790263dbd511d92857a9d31e0b
extra : source : 348f67b15246aa63b83457fde1a17540fa21379e
Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that case open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.
Also includes the patch from bug 1523725.
--HG--
rename : browser/themes/shared/information.svg => toolkit/themes/shared/profile/information.svg
extra : rebase_source : f81be6c98b8248ca9a09c1e3d70cff2f925ad77f
extra : intermediate-source : 198a6d5b96d4127b6d21485a3b1b0ab2d3bc2f72
extra : source : c9d89812bc226ca593119bf440cb4f5e50ac2ace
On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : a033baf831aa8b9fcfa95d1f921364632a837390
Set a telemetry scalar depending on the path taken during profile selection at
startup.
Differential Revision: https://phabricator.services.mozilla.com/D17696
--HG--
extra : rebase_source : 6c797b4a8122db69e61d0d954dcfd726d3d1970e
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : b4608f6e8800af4f154daf0e0262f521c8ebd9fd
extra : intermediate-source : ba34b021c8e995ec7fc7c7fbb3dcc5dcf268278c
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : 24feb46363b5e43f35b51614d9dc6ae20ae49b65
extra : amend_source : 3c2051b98f19dc3288c59b0028db7d33c6953be3
extra : intermediate-source : 8404cc6140177a40c7086ddd4bf5d84735681048
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
We already take steps in `IndexOf` to avoid bounds checks--by using
direct pointer accesses--and we should do the same thing for binary
searches as well.
MOZ_THREAD_LOCAL currently assumes its invocations live in the global
namespace, which may not always be true, e.g. when declaring a static
class member whose enclosing class lives in `namespace mozilla` or
similar. We should qualify the name lookups required to always start
from the global namespace to avoid such problems.
The text in the <th> element was causing intermittent fuzz due to
antialiasing. This patch removes the text to eliminate the problem.
Differential Revision: https://phabricator.services.mozilla.com/D18092
--HG--
extra : moz-landing-system : lando
Note that the dirty rect assertions don't seem to quite work yet, but
Glenn is going to take over that last piece.
Depends on D17995
Differential Revision: https://phabricator.services.mozilla.com/D17996
--HG--
extra : moz-landing-system : lando
The current code panics with an out-of-bounds access here if picture
caching is used outside an iframe.
Depends on D17994
Differential Revision: https://phabricator.services.mozilla.com/D17995
--HG--
extra : moz-landing-system : lando
Per discussion with gw, the current behavior is an oversight. We also
want to expose this to wrench.
Depends on D17993
Differential Revision: https://phabricator.services.mozilla.com/D17994
--HG--
extra : moz-landing-system : lando
There are various testing-only things we want to do here, specifically
copying around dirty regions, and shrinking the tile size. We could make
each of these specific options and thread them all through to the right
places, but that adds complexity without a use-case. So we just add a
simple testing mode for wrench.
Differential Revision: https://phabricator.services.mozilla.com/D17991
--HG--
extra : moz-landing-system : lando
When destroying the target, Target.destroy (for local tabs) only calls DebuggerClient.close,
which isn't going to call `detach`. But we still do need to unregister
the tabNavigated/frameUpdate listener to prevent unecessary event from firing.
Depends on D17609
Differential Revision: https://phabricator.services.mozilla.com/D17610
--HG--
extra : moz-landing-system : lando
This patch makes it so that all target fronts inherits from a Target class mixin.
We are using a mixin as fronts should inherit from a custom Front class,
which is augmented with its own RDP request and events defined in its spec.
(This is done via FrontClassWithSpec(spec))
Depends on D15830
Differential Revision: https://phabricator.services.mozilla.com/D15831
--HG--
extra : moz-landing-system : lando