Widgets that show content in an iframe appear blank while being dragged on New Tab
Categories
(Firefox :: New Tab Page, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: nina-py, Assigned: nina-py)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Dragging a widget in the New Tab widgets row moves a picture of the widget rather than the widget itself. For most widgets that is indistinguishable, because the picture is a faithful copy. For the Crossword widget it is not: the puzzle is drawn by a separate page loaded in an iframe, and none of it appears in the picture, so only the widget's outline and heading follow the cursor.
This is not specific to Crossword. The drag image comes from setDragImage, which rasterises through PresShell::RenderNode, and a remote iframe refuses to paint unless the paint target is a recording one. The Crossword iframe points at a Merino origin, so under Fission it runs in its own process and cannot be included in the drag image at all. Any widget that shows content from an iframe has the same problem, and more such widgets are planned.
Steps to reproduce:
- Enable a few widgets, including the Crossword widget.
- Open a new tab and wait for the puzzle to render.
- Drag the Crossword widget by its heading.
Expected: the widget looks the same while it is being dragged as it does at rest.
Actual: the body of the widget is blank, and only the outline and heading move.
Fixing this means not relying on the platform drag image for this row. Moving the real element with a CSS transform keeps the iframe attached and rendering for the whole drag.
|
Assignee | |
Comment 1•2 months ago
|
||
Widget reordering on New Tab no longer uses HTML drag and drop. The row follows
the pointer directly and moves the widget itself, so a widget that draws its
content in an iframe keeps rendering all the way through the drag instead of
going blank. Only the widget being dragged changes how it moves: the animation
that slides the others into place is the one added in bug 2049472, reused as is.
That file is untouched, though its React wrapper now has no callers and could be
removed separately.
Two behaviours change as a side effect, both deliberate. Releasing a widget over
a gap between widgets, or outside the row, now keeps the position shown on
screen instead of snapping back; Escape is the only way to cancel. Reordering by
touch is no longer possible, which previously worked on Windows alone through an
undocumented double tap and drag.
A browser test for reordering was written and is not included here. It passes,
but every browser test finishes with a check that the compositor has gone idle,
and merely rendering the widgets row keeps it awake. That happens with no drag
at all, so it is a pre-existing problem rather than something this patch
introduces, and it is being filed separately.
|
||
Comment 3•28 days ago
|
||
| bugherder | ||
|
||
Updated•21 days ago
|
Description
•