We can't add the flag to EXE files unless we do either
* Make the CRT an SxS assembly (bug 1733734) or
* Ship the redistributable installer to install the CRT to System32.
Because otherwise firefox.exe will no longer be able to find the CRT.
Differential Revision: https://phabricator.services.mozilla.com/D210639
Adds logic that ensures that the SelectTranslationsPanel
cannot be resized off the bottom edge of the screen when
click-and-dragging the vertical textarea resizer within
the panel.
Depends on D209396
Differential Revision: https://phabricator.services.mozilla.com/D209178
Determines if the SelectTranslationsPanel was positioned before
opening such that the bottom corner of the panel is the anchor
point. This causes the text-area resizer to grow the panel
upward even though the user is dragging downward, so we should
disable resizing in this case.
Differential Revision: https://phabricator.services.mozilla.com/D209396
I really thought this was already the case. It was a bit of a shock to debug a non-update-related test and discover that the failure was because update was just attempting to run normally while the test did something unrelated. In general, we shouldn't have the updater running during tests that aren't testing updater functionality. It cause test failures by contacting the real update url or by throwing errors when attempting to use features that aren't available during that test.
Differential Revision: https://phabricator.services.mozilla.com/D209130
The earlier patches in this stack (a) made it possible to await on the stub to complete and (b) ensured that the update system initiates properly regardless of when and if the update service stub is invoked. This allows us to remove explict stub invocations in some cases and to have the await on the results in others.
Differential Revision: https://phabricator.services.mozilla.com/D209129
In order to do this without initializing the update system this early, we move the functionality to the stub, add an XPCOM interface for it, and convert it to new-style class using the `class` keyword.
Differential Revision: https://phabricator.services.mozilla.com/D209128
A number of changes are made as part of this patch:
- A consistent way of initializing update is created. This is automatically run when methods that need it are invoked.
- The "post-update-processing" notification has been removed. Post update processing is now done through the new `nsIApplicationUpdateService.init` or `nsIApplicationUpdateService.internal.postUpdateProcessing`.
- Post update processing no longer waits for the sessionstore-windows-restored observer service notification
- Post update processing is no longer invoked only when the `update.status` file exists. It is now run unconditionally.
- Explicitly initialize before we potentially clean up updates from the update UI.
Note that the update service stub and a few consumers of it ought to be able to wait for post update processing to be done but they currently do not. That will be done later in this patch stack when we rework the stub.
Differential Revision: https://phabricator.services.mozilla.com/D209126
The internal/external state needs to be piped through to #updateCheck, where the asynchrous initialization will need to be done.
Differential Revision: https://phabricator.services.mozilla.com/D209125
We currently seem to use `standardInit` and `testPostUpdateProcessing` interchangeably. In the future, we should not do this. `standardInit` will do the standard initialization process, which only ever runs once. If we want to run postUpdateProcessing again, even after initialization has already run, we should call into `testPostUpdateProcessing`. I believe that this makes sense considering the naming, but existing uses don't always match this expectation.
There are many places where we do things like
```
await setupUpdaterTest(...);
runUpdate(...);
await standardInit();
```
This doesn't make sense. We will already have initialized update by that point. This patch replaces uses of `standardInit` that are used this way with `testPostUpdateProcessing`.
Differential Revision: https://phabricator.services.mozilla.com/D209608
This is because initializing the update service will be an asynchronous process. This is introduced later in this patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D209121
Aside from tests (which will be in the next patch in the stack), this specifically leaves two instances of readyUpdate unchanged - the one in BrowserContentHandler's `getArgs` and the one in UpdatePing's `_getActiveUpdate`. In both of these cases what is actually wanted is the update that was just installed. It's only because of the (fairly arbitrary) order that things are started up in that `readyUpdate` still happens to contain this value when these things run. Later in this patch stack we will add something more appropriate for this. But in the meantime, it doesn't make sense to convert functions to be asynchronous that will not ultimately need to be asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D209115
I want the initialization function that I'm going to add later in the patch stack to be asynchronous, so the update entry points should be asynchronous functions.
Differential Revision: https://phabricator.services.mozilla.com/D209109
Looking forward, a goal of this patch stack is to have external interfaces automatically initialize the update system before doing anything that requires that. However, during that initialization, we need to make sure that we don't accidentally cause recursion by invoking an external interface that also does initialization. To do this, we will require special, privileged access to this functionality that doesn't do the initialization.
An appealing way of implementing this is to have `UpdateManager` implement both `nsIUpdateManager` and `nsIUpdateManagerInternal`. However, by experimentation, this seems to allow us to use the internal functions directly on the update manager object, even without ever QIing it to `nsIUpdateManagerInternal`. This is undesirable both because it allows consumers to use internal interfaces sort of implicitly and because it means that if we move functionality from the public interface to the private one, existing consumers of that interface could more easily be missed since the method is still available on the update manager object that it's already using.
This commit doesn't actually add any attributes or methods to the new interface. That will be done later in the patch stack.
Differential Revision: https://phabricator.services.mozilla.com/D209106
This patch consolidates the flag appending process into a single
location, reducing redundant flag appending code across multiple areas.
Differential Revision: https://phabricator.services.mozilla.com/D210585
