Content displayed on mouseover is now impossible to capture with Screenshots
Categories
(Firefox :: Screenshots, defect)
Tracking
()
People
(Reporter: sfoster, Assigned: niklas)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
RyanVM
:
approval-mozilla-esr128+
|
Details | Review |
3.31 MB,
video/mp4
|
Details |
This was reported as a issue on connect.mozilla.org where a popup details for a data point in a graph which get revealed on hover, disappear once the Screenshots UI is opened and the mouse moves within it. The original issue was observed in paid, browser-based software but this interaction is common for canvas-based graphs and charts.
Similar STR:
- Open https://www.chartjs.org/docs/latest/samples/tooltip/interactions.html
- Hover over one of the data points to reveal the little "tooltip"
- Use the ctrl+shift+s tooltip to attempt to capture what is on-screen in a screenshot
Expected results:
- The tooltip remains visible and can be capture in a screenshot
Actual results:
- The tooltip immediately disappears as the Screenshots UI opens.
Reporter | ||
Comment 1•2 months ago
|
||
These STR aren't quite the same, and I'm able to reproduce the same results with screenshots.browser.component.enabled
toggled false, but the OP on connect says this was working before v127 and now is not, so better STR would be good if someone can find a more comparable example.
Comment 2•2 months ago
|
||
Set release status flags based on info from the regressing bug 1870127
:niklas, since you are the author of the regressor, bug 1870127, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Comment 3•2 months ago
|
||
Updated•2 months ago
|
Pushed by nbaumgardner@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/28acb043406c Prevent some more mouse events from reaching the content page. r=sfoster
Comment 5•2 months ago
|
||
bugherder |
Comment 6•2 months ago
|
||
Set release status flags based on info from the regressing bug 1870127
Comment 7•2 months ago
|
||
:niklas do you want to add a beta and esr128 uplift request on this?
How about a release uplift for possible inclusion in a later Fx128 dot release?
Assignee | ||
Comment 8•2 months ago
|
||
Comment on attachment 9410849 [details]
Bug 1905468 - Prevent some more mouse events from reaching the content page. r=sfoster,kcochrane
Beta/Release Uplift Approval Request
- User impact if declined: Users won't be able to screenshot elements that listen to certain mouse events.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: STR:
- Go to https://www.chartjs.org/docs/latest/samples/tooltip/interactions.html
- Hover over one of the data points to reveal the little "tooltip"
- Open screenshots and select a region to capture the tooltip
ER: The tooltip should remain visible to be captured in a screenshot.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This only prevents some events from reaching the content page while screenshots is open. We already do this for most mouse/pointer/touch events and are only adding a few more events in this patch. We can also pref this off if needed via
screenshots.browser.component.preventContentEvents
. - String changes made/needed: No
- Is Android affected?: No
Assignee | ||
Updated•2 months ago
|
Updated•2 months ago
|
Comment 9•2 months ago
|
||
Comment on attachment 9410849 [details]
Bug 1905468 - Prevent some more mouse events from reaching the content page. r=sfoster,kcochrane
Approved for 129.0b2
Updated•2 months ago
|
Updated•2 months ago
|
Comment 11•2 months ago
|
||
I reproduced the initial issue on Firefox 129.0a1 on macOS 13 and Windows 10.
While verifying the fix using the latest Nightly 130.0a1 on macOS 13, Windows 10, and Ubuntu 22.04, I noticed that the first time Screenshots mode is enabled, the tooltip is dismissed and not visible in the screenshot. This issue occurs only the first time Screenshots mode is enabled after the browser starts; it does not happen in a new tab or after refreshing the page. Please see the attached screen recording for more details, where it can be seen how the tooltip is still dismissed after a Firefox restart.
Niklas and Sam, is this expected in any way? Should I file a new bug to cover this scenario?
Assignee | ||
Comment 12•2 months ago
|
||
Hmmm, if you could file a new bug for this, that would be great!
I'm not exactly sure what is going on.
Comment 13•2 months ago
•
|
||
Verified as fixed using Firefox 129.0b2 on macOS 13, Ubuntu 22 and Windows 10 - the tooltip is captured within the Screenshot - for the scenario mentioned in Comment 11 I filed Bug 1907285.
Based on this and on Comment 11, marking this issue as Verified on firefox129 and firefox130.
Comment 14•2 months ago
|
||
Comment on attachment 9410849 [details]
Bug 1905468 - Prevent some more mouse events from reaching the content page. r=sfoster,kcochrane
Approved for 128.1esr.
Updated•2 months ago
|
Updated•2 months ago
|
Comment 16•2 months ago
|
||
Verified as fixed using Firefox 128.1.0esr Build ID: 20240711165656 (from Treeherder) on macOS 13, Ubuntu 22.04 and Windows 10 x64.
Comment 17•2 months ago
|
||
Comment on attachment 9410849 [details]
Bug 1905468 - Prevent some more mouse events from reaching the content page. r=sfoster,kcochrane
Approved for 128.0.2
Updated•2 months ago
|
Comment 19•2 months ago
|
||
Verified as fixed using Firefox 128.0.2 on macOS 13, Windows 10 and Ubuntu 22.04.
Comment 20•2 months ago
|
||
Added to the 128.0.2 relnotes:
Fixed an issue where content displayed on mouseover was not captured in a screenshot.
Description
•