This test also has the same dashed border and occasional fuzziness
that grid-track-intrinsic-sizing-003.html does with DC enabled.
Differential Revision: https://phabricator.services.mozilla.com/D60947
--HG--
extra : moz-landing-system : lando
Changes:
Migrate over the platform of `mochitest-chrome` to ubuntu1804:
Mark as expected failure one test, and expand the disable annotation of another test to include all platform variants of linux.
Resulting runs have some intermittent failures but nothing significant.
Differential Revision: https://phabricator.services.mozilla.com/D60612
--HG--
extra : moz-landing-system : lando
* getAttributeValue
* cloneAttribute
* splitNode
* joinNodes
* markNodeDirty
* removeEditorObserver
are not used from script. Therefore, we can get rid of them from `nsIEditor`.
However, `EditorBase::GetAttributeValue()` is referred by
`HTMLEditor::CopyCellBackgroundColor()` and it's just a wrapper of
`Element::GetAttr()`. Therefore, this patch makes
`HTMLEditor::CopyCellBackgroundColor()` use `Element::GetAttr()` directly.
And also `EditorBase::MarkNodeDirty()` is used from some friend classes.
Therefore, this patch redesigns it as `MarkElementDirty()` and make all of
them check whether the method call destroys the editor.
Differential Revision: https://phabricator.services.mozilla.com/D60796
--HG--
extra : moz-landing-system : lando
I made `nsContentUtils::DispatchInputEvent()` update validity of event target
before dispatching `eEditorInput` event in bug 1584963. However, this is not
enough because it updates validity only when the type of `<input>` element is
`mail`, but it's required for other types, for example, `<input required>`.
This patch reverts the hack added in bug 1584963, instead, makes
`TextControlState::SetValueWithoutTextEditor()` notifies `TextControlElement`
of value change before dispatching `eEditorInput` event because it may have made
damage to the performance if `nsContentUtils::DispatchInputEvent()` updated
**all** validity state of the event target.
Differential Revision: https://phabricator.services.mozilla.com/D60828
--HG--
extra : moz-landing-system : lando
For now I didn't change tests to not open the submenu when only generating a password as it should be harmless.
Differential Revision: https://phabricator.services.mozilla.com/D60641
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
On pages with many render tasks (typically a lot of text shadows), we spend a lot of time moving RenderTask which is a fairly large struct into the render graph's buffer. This patch avoids it by using the VecHelper trick of allocaitng space before initializing the value. Some RenderTask::new_* methods which take the render task graph in parameter were modified to add the task and return the task ID to work around borrow-checking restriction.
Differential Revision: https://phabricator.services.mozilla.com/D60854
--HG--
extra : moz-landing-system : lando
For mozilla-central, all the code related to taskgraph lives in
taskcluster/taskgraph. Thunderbird's build requirements are evolving, and
we want to be able to have repository-specific code. The natural place for it
to live is an a package beside taskcluster/ci. Add that to python path,
and provide some hooks for adding to the various registries in taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D60540
--HG--
extra : moz-landing-system : lando
This patch moves the pref setting of "devtools.responsive.browserUI.enabled"
within the add_task functions, so that the prefs are in a consistent state
throughout the task.
Differential Revision: https://phabricator.services.mozilla.com/D60590
--HG--
extra : moz-landing-system : lando
Second part: trace the updates that are sent to the DataStore, and save
at least the Insert/Remove and ItemUID as part of the wr-capture.
(We could expand this with more info, eg. the actual Keys, later).
TileView then reads them back and generates a color coded report to
overlay with the page view. This helps to see the types and amounts of
interned primitives that lead to cache invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D60619
--HG--
extra : moz-landing-system : lando
On Windows, optimized surfaces can become invalid due to a device reset
or GPU process crash when D2D draw targets were being used. This is
because SourceSurfaceD2D1 checks if the D2D context has changed from the
one it was optimized for.
We assumed when creating a DrawableFrameRef that if we don't have
imgFrame::mRawSurface, then we must have an imgFrame::mOptSurface. This
is incorrect and causes SurfaceCache to believe it has a valid
DrawableSurface, even if the underlying optimized surface cannot be used
for drawing (or has already been freed).
If we can't draw the image, it goes missing from the screen. But since
the cache thinks it has a valid surface, we never actually redecode it.
With this patch, we now check if the imgFrame::mOptSurface has been
freed already, and if not, that it remains valid for drawing purposes.
If either condition is true, the SurfaceCache entry will be removed,
thus permitting a redecode attempt.
Differential Revision: https://phabricator.services.mozilla.com/D60834
--HG--
extra : moz-landing-system : lando
