Open Bug 1652823 Opened 1 year ago Updated 1 year ago

The fixed header on does not dissapear when I switch to a tab containing another fixed header (


(Core :: Graphics: WebRender, defect)

79 Branch
Windows 10



Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- unaffected
firefox79 --- affected
firefox80 --- affected


(Reporter: haypro.narek, Unassigned)


(Blocks 1 open bug)


(Keywords: correctness)


(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

  1. Open tab
    Scroll a bit down till the fixed header appears.
  2. Create a new tab and log in and play music as usual on
  3. Make sure you have a fixed dark header on soundcloud.
  4. Now switch the tab to

Actual results:

The dark header of does not disappear after switching to I can see it over Again: I see the upper bar from over the another site
See here:

Expected results:

The upper bar should disappear.

Component: Untriaged → Graphics
Product: Firefox → Core
See Also: → 1638490

Can you attach the contents of your about:support as a text file?

Flags: needinfo?(haypro.narek)
Blocks: wr-79
Severity: -- → S3
Priority: -- → P3
Attached file about:support
Flags: needinfo?(haypro.narek)

I haven't been able to reproduce locally so far (tested on a Mac and a Windows machine). Jessie, how easy is it to reproduce - was it happening regularly or just once?

Would you be able to set gfx.webrender.compositor to false, restart the browser (need to do an exit from dock on Mac), and see if you can reproduce then? (I suspect that will stop it occurring - not a good fix - but would help narrow down what part of the code may be causing it). Remember to change that pref back to normal after testing though!

Flags: needinfo?(gwatson)

I reproduced this pretty easily yesterday, but am not able to do so yet again today. Will keep trying.

haypro.narek, does this reproduce for you easily, every time you visit these two pages? Do you ever see it with other websites?

Flags: needinfo?(haypro.narek)

We had two regressions that looked similar:
Bug 1653413 caused regressions with DirectComposition on Win10.
Bug 1640960 caused regressions on macOS.
Comment 0 might have been caused by Bug 1653413, and comment 2, comment 10 by bug 1640960.

Blocks: wr-80
No longer blocks: wr-79
Component: Graphics → Graphics: WebRender
Flags: needinfo?(haypro.narek)
OS: Unspecified → All
Regressed by: 1640960
Hardware: Unspecified → All

Sorry, I have to correct. Different bugs have been mixed:
comment 0 is Win10 WebRender on 79.0b4. Therefore it can't be bug 1653413 or bug 1640960.
comment 2 and comment 10 were caused by bug 1640960.

Blocks: wr-79
No longer blocks: wr-80
OS: All → Windows 10
No longer regressed by: 1640960
Hardware: All → x86_64

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --
Blocks: wr-80
No longer blocks: wr-79

I can reproduce this in 80.0b8. Here is another demonstration of the bug:

Unfortunately I can not recognize the exactly conditions to reproduce it.

Keywords: correctness
No longer blocks: wr-80

@ktaeleman: try repro

Flags: needinfo?(ktaeleman)
No longer blocks: wr-81

Still easily reproduces on latest nightly with repro steps of reporter.
@Glenn: gfx.webrender.compositor false does not show the issue, so it must be related to this.

Let me know if you want me to generate some logging or so!

Flags: needinfo?(ktaeleman) → needinfo?(gwatson)

I can reproduce this bug on macOS.

I haven't been able to reproduce locally yet, but will try again today / tomorrow. Markus is going to try and look at it this week as he is able to reproduce locally.

Flags: needinfo?(gwatson)

I can no longer reproduce this :(

@Kris try repro again

Flags: needinfo?(ktaeleman)
No longer blocks: gfx-82
No longer blocks: gfx-83
Flags: needinfo?(ktaeleman)
You need to log in before you can comment on or make changes to this bug.