The null is unnecessary because mDrawTarget is already null-checked above:
If mTarget is non-null, then mDrawTarget = mTarget so mDrawTarget is non-null.
If mTarget is null, then we would enter a branch that had another null check
for mDrawTarget.
As for the assertion: When rendering to an external target (reftests),
LayerManagerComposite always sets the invalid region to the entire window, so it
should never be empty here.
Differential Revision: https://phabricator.services.mozilla.com/D41677
--HG--
extra : moz-landing-system : lando
There was an interesting "ExpandToEnclose(IntPoint(0, 0))" call in
CreateRenderTargetForWindow that snuck in some surprising behavior that this
change makes a bit more visible.
Differential Revision: https://phabricator.services.mozilla.com/D41676
--HG--
extra : moz-landing-system : lando
In the past, BeginFrame would clip mDrawTarget to the invalid region and then have
CreateRenderTargetForWindow clear a rectangle. So it was effectively clearing a
region, but only if BeginFrame's region clip happened to be set on the correct
DrawTarget. In the case where a back buffer was used, this was not the case:
The clip would be on mDrawTarget but the clear would happen on the back buffer
draw target. So we were clearing more than necessary.
Now we limit clearing to the invalid region even if a back buffer is used.
Differential Revision: https://phabricator.services.mozilla.com/D41675
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
This should be equivalent to what we had before but clearer.
Before this patch, we would reallocate the back buffer if
- the back buffer was larger than the client size (meaning the window had shrunk) or
- the invalid region didn't fit in the back buffer.
Whenever the window is resized, we have a frame where the invalid region covers
the entire window, and thus size would be equal clientSize in that frame.
So effectively, the back buffer size was always kept in sync with the client size.
Differential Revision: https://phabricator.services.mozilla.com/D41671
--HG--
extra : moz-landing-system : lando
Updating parking_lot would allow us to avoid dependency duplication when WebGPU tree is vendored.
Differential Revision: https://phabricator.services.mozilla.com/D42557
--HG--
rename : third_party/rust/parking_lot_core/src/thread_parker/wasm.rs => third_party/rust/parking_lot_core/src/thread_parker/wasm_atomic.rs
extra : moz-landing-system : lando
`HTMLEditRules::mReturnInEmptyLIKillsList` stores value of
`editor.html.typing.returnInEmptyListItemClosesList` at construction, and it's
set to true unless the pref value is `"false"`. However, this pref isn't
registered in anywhere (all.js, firefox.js, etc) nor used in comm-central
and BlueGriffon.
Even if I search the pref in the web, I don't see any information so that
this hidden pref must not be used anybody. Therefore, this patch just removes
this member.
Differential Revision: https://phabricator.services.mozilla.com/D42262
--HG--
extra : moz-landing-system : lando
This patch includes a logic change. `HTMLEditRules::mListenerEnabled` is used
for storing 2 state. One is that whether `HTMLEditRules` can handle the legacy
listener methods (they came from `nsIEditActionListener`) with `mHTMLEditor` or
not. The other is that whether current edit sub-action handler temporarily
disables the listeners for performance or not.
For the former, we can check same result with `HTMLEditRules::mInitialized`
and `HTMLEditRules::mHTMLEditor`.
However, the latter, current design is obviously wrong. Currently,
`HTMLEditRules::mListenerEnabled` is set only to `false` temporarily from
`WillInsertText()`, but the state will be affected to other edit sub-actions
which are nested by mutation event listeners. So, currently,
`HTMLEditRules::mDocChangeRange` may not contain modified range caused by
nested edit sub-actions.
For solving this bug, this patch moves it into `EditSubActionData` rather
than `HTMLEditor` and `TopLevelEditSubActionData`.
Differential Revision: https://phabricator.services.mozilla.com/D42107
--HG--
extra : moz-landing-system : lando
The members of `HTMLEditRules` which are used only while `WillDoAction()` and
`DidDoAction()` are called should be moved to specific stack only struct
`EditorBase::EditSubActionData`.
Differential Revision: https://phabricator.services.mozilla.com/D42106
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::mUtilRange` is used only for the argument of
`HTMLEditRules::UpdateDocChangeRange()`. However, it does not need to be
a range instance since it compares its start and
`TopLevelEditSubAction::mChangedRange->StartRef()`, and its end and
`TopLevelEditSubAction::mChangedRange->EndRef()`. Therefore, with rewriting
it as taking 2 `EditorRawDOMPoint`s, we don't need `mUtilRange`.
Differential Revision: https://phabricator.services.mozilla.com/D42105
--HG--
extra : moz-landing-system : lando
This patch makes `StyleCache` not inherit `ItemProp` because `MOZ_COUNT_CTOR`
and `MOZ_COUNT_DTOR` do not work well with `AutoTArray` and there is no reason
to do that since nobody treat `StyleCache` instance with `ItemProp` pointer.
Differential Revision: https://phabricator.services.mozilla.com/D42103
--HG--
extra : moz-landing-system : lando
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
