Closed Bug 1686729 Opened 4 years ago Closed 4 years ago

Ruffle content (Homestar Runner) overlaps window chrome

Categories

(Core :: Graphics: WebRender, defect)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- unaffected
firefox85 --- unaffected
firefox86 --- fixed

People

(Reporter: chutten, Assigned: lsalzman)

References

(Regression)

Details

(Keywords: csectype-spoof, regression)

Attachments

(3 files)

STR

  1. Visit https://homestarrunner.com/main/27 in a window too short for all the content
  2. Wait for the big play button to show up
  3. Scroll down to read the notice 'What is that big play button'

Expected

  • The ruffle player's black background would be clipped by the toolbar.

Actual

  • The ruffle player overlaps the toolbar.

Linux Nightly 20210114

Does not affect Windows. mozregression time.

19:54.63 INFO: No more integration revisions, bisection finished.
19:54.63 INFO: Last good revision: 64e6fc7cfaeb0b7bdbec7e3e32a0157c34c2b631
19:54.63 INFO: First bad revision: bb634a5d7268ebd3ed7a57ae12ac9513900e3a73
19:54.63 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=64e6fc7cfaeb0b7bdbec7e3e32a0157c34c2b631&tochange=bb634a5d7268ebd3ed7a57ae12ac9513900e3a73

Points to bug 1678652, and since that's a bug about Canvas, I'm tempted to believe it. ni?jgilbert, am I completely off base here?

Flags: needinfo?(jgilbert)
Regressed by: 1678652
Has Regression Range: --- → yes

Set release status flags based on info from the regressing bug 1678652

Keywords: sec-low
Attached file raw about:support
Group: firefox-core-security
Keywords: sec-low

Can the website predict when this overlapping will happen and by how much? If so you could in theory do a perfect URL bar spoof (for people who haven't customized their toolbar) by intentionally opening a pop-up with a small-enough size to trigger the bug, perhaps imitating an OAuth sign-in (a pop-up for that is pretty rare these days, but it's security-positive to make sure users can see the "real" site name in the addressbar and some hosting sites prefer that than a navigation/navigation-back). That could be sec-high, but maybe there's enough limitations (including being linux-only) that could justify sec-moderate instead.

Group: firefox-core-security → gfx-core-security
Component: General → Canvas: WebGL
Keywords: csectype-spoof
Product: Firefox → Core

(In reply to Chris H-C :chutten from comment #1)

Does not affect Windows. mozregression time.

19:54.63 INFO: No more integration revisions, bisection finished.
19:54.63 INFO: Last good revision: 64e6fc7cfaeb0b7bdbec7e3e32a0157c34c2b631
19:54.63 INFO: First bad revision: bb634a5d7268ebd3ed7a57ae12ac9513900e3a73
19:54.63 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=64e6fc7cfaeb0b7bdbec7e3e32a0157c34c2b631&tochange=bb634a5d7268ebd3ed7a57ae12ac9513900e3a73

Points to bug 1678652, and since that's a bug about Canvas, I'm tempted to believe it. ni?jgilbert, am I completely off base here?

I don't think that's the root cause, but rather it exposed the problem for your machine.

Flags: needinfo?(jgilbert)

I'm inclined to say this is a compositing issue. Your about:support says SW-WR.

Can you disable WR?
gfx.webrender.force-disabled => true

What about enabled WR but disabled SWGL?
gfx.webrender.enabled => true
gfx.webrender.force-disabled => false
gfx.webrender.software => false

Flags: needinfo?(chutten)

Ok I tested on my machine. "WebRender (Software)" does reproduce, though WR SW d3d11 seems ok.

Component: Canvas: WebGL → Graphics: WebRender
Flags: needinfo?(chutten) → needinfo?(lsalzman)

This was on Windows, too.

Name 	Firefox
Version 	86.0a1
Build ID 	20210120095121

Update History 	
Update Channel 	nightly
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
OS 	Windows_NT 10.0 19042

Compositing	WebRender (Software)
OS: Linux → All
Flags: needinfo?(lsalzman) → needinfo?(matt.woodrow)

(In reply to Jeff Gilbert [:jgilbert] from comment #6)

I'm inclined to say this is a compositing issue. Your about:support says SW-WR.

Can you disable WR?
gfx.webrender.force-disabled => true

What about enabled WR but disabled SWGL?
gfx.webrender.enabled => true
gfx.webrender.force-disabled => false
gfx.webrender.software => false

Confirm that disabling WR fixes the problem (no overlap).

Confirm that WR enabled but disabled SWGL fixes the problem (no overlap).

Confirm that setting those prefs all back to default brings the problem back (overlap).

(In reply to Daniel Veditz [:dveditz] from comment #4)

Can the website predict when this overlapping will happen and by how much? If so you could in theory do a perfect URL bar spoof (for people who haven't customized their toolbar) by intentionally opening a pop-up with a small-enough size to trigger the bug, perhaps imitating an OAuth sign-in (a pop-up for that is pretty rare these days, but it's security-positive to make sure users can see the "real" site name in the addressbar and some hosting sites prefer that than a navigation/navigation-back). That could be sec-high, but maybe there's enough limitations (including being linux-only) that could justify sec-moderate instead.

It'd need to detect the compositor, apparently, as well as control the scroll y of the page (setting it to the y of the rendered artefact + height of the chrome). Could do an overlap in that case with the default theme and use it to mess with what any part of the chrome looks like, but you'd have to make some assumptions about theming as well as the presence of toolbars, addons, and customized UI elements.

SW-WR is still nightly only, so this bug only affects nightly.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Flags: needinfo?(matt.woodrow)

(In reply to Lee Salzman [:lsalzman] from comment #10)

SW-WR is still nightly only, so this bug only affects nightly.

As well, and still only within the nightly SW-WR experiment, this is only expected to affect Linux users and Windows 7 users.

The bug is that the destination rectangle for composition is sometimes flipped if the source requires it. When this happens, it fails to properly intersect with the clip rectangle. The patch here fixes this by flipping the source rectangle instead, so that the destination and clip rectangles can intersect without interference.

Group: gfx-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: