For avoiding allocation cost of `RangeItem`, it should be stored by `HTMLEditor`
and reused by all `TopLevelEditSubActionData` instances for the editor instance.
Differential Revision: https://phabricator.services.mozilla.com/D42102
--HG--
extra : moz-landing-system : lando
Most member variables of `HTMLEditRules` are temporary used while between
`BeforeEdit()` and `AfterEdit()` are called or `WillDoAction()` and
`DidDoAction()` are called.
The former means the data should be stored during top-level edit sub-action
is set. Therefore, this patch creates a struct, `TopLevelEditSubActionData`
and make it a member of `AutoEditActionDataSetter`. Then, makes
`EditorBase::TopLevelEditActionDataRef()` return reference of it.
And also this patch moves `HTMLEditRules::mDidDeleteSelection` into it.
Differential Revision: https://phabricator.services.mozilla.com/D42096
--HG--
extra : moz-landing-system : lando
* Add a new extensionStorage actor to enable inspection of data stored by an extension using the WebExtension storage.local API in the Storage panel client.
* The actor is only listed when the developer toolbox is targeting an extension process. For multi-process Firefox (e10s), this applies to only the toolbox accessed in about:debugging.
* The actor is gated behind a preference: devtools.storage.extensionStorage.enabled. This preference is set to false by default.
* The Storage panel displays storage item values as strings. If a storage item value is not JSON-stringifiable, it will be displayed in the table as "Object".
* It should be noted that extension storage.local’s storage backend is in the process of migrating from a JSON file to IndexedDB as of Firefox 66 for performance reasons. This actor only works for extensions that have migrated to the IndexedDB storage backend.
* In-line comments referencing Bugs 1542038 and 1542039 indicate places where the implementation may differ for local storage versus the other storage areas in the actor.
Differential Revision: https://phabricator.services.mozilla.com/D34415
--HG--
extra : moz-landing-system : lando
Bug 1522547 overlooked the need for specifying map entries for both nsISupports
and nsIDocumentActivity and only had the latter. This changeset adds the missing
nsISupports case.
Differential Revision: https://phabricator.services.mozilla.com/D42563
--HG--
extra : moz-landing-system : lando
This can be verified by starting Firefox with the environment variables
CA_LAYER_SURFACE=0 CA_COLOR_OPAQUE=1
Transparent parts of the window will be red, and opaque parts will be green.
With this patch, the main browser window will be opaque except for the vibrant
areas, i.e. the tab bar and any open sidebars, which will be transparent.
Full screen video will be opaque.
Differential Revision: https://phabricator.services.mozilla.com/D40555
--HG--
extra : moz-landing-system : lando
Previously, additional dependencies (such as opacity bindings and
transforms) were stored in a simple hash set, which meant they
could not be correlated with primitive bounding rects (and thus
could not be used to derive dirty rects of a tile).
Now, by scanning the primitive list which contains the bounding
rect, we can also find additional dependencies for that primitive.
This will be used in future to create exact dirty rects (for
debugging / regression testing) and allow us to generate a
dependency descriptor for a split or merged tile from an existing
descriptor.
This patch also fixes a case where opacity bindings could result
in unnecessary invalidations, by retaining the opacity bindings
state across display lists.
Differential Revision: https://phabricator.services.mozilla.com/D42473
--HG--
extra : moz-landing-system : lando
* Add an extra param to promptToChangePassword to indicate whether a duped/superceded login should be deleted
* Add a raft of tests for promptToChangePassword as it applies to generated passwords and auto-saved logins
Differential Revision: https://phabricator.services.mozilla.com/D40115
--HG--
extra : moz-landing-system : lando
This is not something that happens under normal circumstances, but it
can happen when you go fancy and run multiple configures in parallel
with different objdirs, and old-configure doesn't exist in the first
place ; then one configure may overwrite old-configure while another is
starting to execute it, resulting in the latter nor executing
old-configure completely.
Differential Revision: https://phabricator.services.mozilla.com/D42428
--HG--
extra : moz-landing-system : lando
This is now dead code which will be kept alive by the vtable,
and introduces needless overhead inside the permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D42207
--HG--
extra : moz-landing-system : lando
This patch also includes some spot fixes for the storage principal
support on the XUL browser element.
Differential Revision: https://phabricator.services.mozilla.com/D42203
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
Adding `CreateUri` broke MinGW build because of our toolkit issue. We use
dynamic linking for MinGW build in the meantime.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
While working on porting the (audio-playback indicators) bug 1562990 to fission, we saw the potential to delete some methods in nsIDOMWindowUtils because they were not used anymore in our codebase except in a couple of tests files. So now, we should only mute/unmute or change the volume in the parent process. As such, interfaces are added in SpecialPowers to change media muted or volume state from content processes.
Differential Revision: https://phabricator.services.mozilla.com/D41782
--HG--
extra : moz-landing-system : lando
