Closed Bug 1580152 Opened 5 years ago Closed 5 years ago

[Wayland] Window partially or not updated when switching between two tabs

Categories

(Core :: Widget: Gtk, defect, P2)

Product:
Core
Component:
Widget: Gtk
Version:
69 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla71
Tracking Flags:
Tracking Status
firefox70 --- fixed
firefox71 --- fixed

People

(Reporter: vstinner, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(5 files, 1 obsolete file)

firefox_bug_1.jpg
425.60 KB, image/jpeg
Details
firefox_bug_2.jpg
396.80 KB, image/jpeg
Details
about:support of my current Firefox (from Fedora, not the Nightly build)
18.51 KB, application/octet-stream
Details
about:support of my browser - firefox-wayland 69 on fedora 30
18.51 KB, text/plain
Details
Bug 1580152 - [Wayland] Fix rendering glitches on wayland , r?jhorak
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review
Attached image firefox_bug_1.jpg —

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

On Linux using Wayland, sometimes Firefox doesn't repaint the window content when I switch to a new tab, or only the top of the window is repainted. My GPU is "Intel(R) HD Graphics 530 (Skylake GT2)".

Steps to reproduce:

  • Enable Wayland. For example, to test my tests, I type this command in a terminal (in the directory of Firefox nightly): MOZ_ENABLE_WAYLAND=1 ./firefox -safe-mode -ProfileManager -no-remote

  • Get Firefox nightly ("71.0a1 (2019-09-09) (64-bit)"), or latest (stable) Firefox (69.0) from mozilla.org, or run Firefox of Fedora 30 (Firefox 69.0 (64-bit), package: firefox-69.0-2.fc30.x86_64)

  • Open multiple tabs. I'm using:

  • Switch between tabs: sometimes, the windows is only partially repainted or not updated at all. For example, if I come from LinuxFR and goes to LWN, the old LinuxFR content stays. But if I move my mouse cursor, the content is slowly painted by my mouse. Or using ALT-tab twice repaint fully the full window.

  • If the bug doesn't occur, try to scroll in a page and switch to other tabs multiple times

  • If the bug doesn't occur, switch to a different application than Firefox using ALT-tab and use the application, and then try to again to switch to other tabs

In an old bug, I found another method which also managed to reproduce my bug and looks simpler and more reliable, bz #1157784:

STR:

  1. Open the build (firefox.exe -console) with a clean profile.
  2. Go to https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project.
  3. Middle click on the first 6 pictures to open them in new tabs (pictures will open on pages with a much smaller preview, so NOT at full size).
  4. Switch to the console window
  5. Click one of the undisplayed tabs
  6. If the paints don't stop, switch back to the the console window
  7. Click one of the other undisplayed tabs
  8. Repeat until the browser stops painting

Attached screenshots show Firefox when the window is only partially repainted (like top 5 cm of the window). I took a photo using my phone since taking a screenshot repaints the windows.

Attached image firefox_bug_2.jpg —

I followed https://fedoraproject.org/wiki/How_to_debug_Firefox_problems advices.

I can reproduce the bug in Firefox nightly in safe mode with a new empty profile.

Note: my laptop has 2 GPUs, but I disabled the Nvidia driver using modprobe.blacklist=nouveau argument on the Linux command line, to ensure that the bug is reproduced only with the Intel GPU (IGP).

Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64

I think it's a dupe of Bug 1579794 - let's check that when it lands.

btw. can you please attach your about:support content? Thanks.

Flags: needinfo?(vstinner)
Flags: needinfo?(vstinner)

I upgraded my Fedora 30 this morning and I'm quite sure that the bug is new since this upgrade.

I'm quite sure that I was running the Linux kernel version 5.2.9-200.fc30.x86_64 when I had the bug. But I can reproduce the bug with an older Linux kernel: version 5.2.8-200.fc30.x86_64. So I don't think that the Firefox bug is a Linux kernel regression.

btw. can you please attach your about:support content? Thanks.

Sure, done. But it's about:support of my current Firefox (from Fedora, not the Nightly build). Tell me if you need about:support of the 2 other Firefox binaries that I tried in safe mode (stable 69.0 and Nightly 71.0a1).

I tried to downgrade the Linux kernel and gtk3, but I didn't help.

When I downgraded Firefox from firefox-69.0-2.fc30.x86_64 (new) to firefox-68.0.2-1.fc30.x86_64 (old), the problem goes away! So it looks like a regression introduced between firefox-68.0.2-1.fc30.x86_64 (old) and firefox-69.0-2.fc30.x86_64 (new).

Note: I failed to reproduce the bug without Wayland (in X11 mode). That's why I put [Wayland] in the bug title and wrote that I'm using Wayland and MOZ_ENABLE_WAYLAND=1.

I am also affected by this since roughly 4-5 days ago? About every third or fourth tab switch is affected. My solution at the moment is to min and restore the window, which seems to trigger a repaint. When switching to an affected tab, there are often pieces of the incoming page that ARE rendered, like an animated gif or something active, while everything else is invisible (you still see the last tab).

This problem is independent of whether I have hardware accel set in preferences.

I am running Gnome on debian unstable.

Also In my case there is no two-graphic card handoff happening. This is straight skylake intel integrated graphics. It's definitely something new in the firefox rendering process.

I'm experiencing the same bug. I did notice that this only occurs when changing tabs by clicking on the tab-title. When using ctrl+tab or ctrl+shift+tab to change tabs, this never happens.

I'm using fedora 30 with firefox-wayland.

Assignee: nobody → stransky
Priority: -- → P2

Please try latest nightly as Bug 1579794 landed there.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Please confirm the build number that you mean. Would build containing that fix be 71.0a1 (2019-09-10) ? If so, the bug is still present. If not, I'll wait a few hours an test again.

from my about:buildconfig:
Built from https://hg.mozilla.org/mozilla-central/rev/0e0e9c22321ed9f284744cfeb3507710b2d5d606

Yes I can reproduce it with latest nightly too - will look at it ASAP.

The problem here is that we don't clear mPendingCommit flag at WindowSurfaceWayland::Lock() so frame callback can commit non-finished buffer. The fix is a part of Bug 1579849 and I'll back port that to Fedora FF 69.

Can you please try latest nightly as Bug 1579849 has landed? Thanks.

Hm I can still reproduce it with latest nightly when rapidly switching pages although it's less visible.

Hm I can still reproduce it with latest nightly when rapidly switching pages although it's less visible.

The bug is not fixed yet.

I tested Nightly "71.0a1 (2019-09-11) (64 bits)". I failed to reproduce the bug using the second scenario (using "2. Go to https://commons.wikimedia.org/wiki/Category:Gigapixel_images_from_the_Google_Art_Project."). But I still reproduce the bug with my first scenario (open many tabs : lemonde.fr, lwn.net, linuxfr.org, youtube.com, facebook.com), and switch frequently between tabs, use ALT+TAB (focus to another window, then focus back to Firefox), repeat.

  • Recently we're missing some drawings as we disabled flushing cached images in frame callback.
    Let's enable it again and make sure we don't flush the drawings between Lock()/Commit() compositor
    calls.

  • When we draw directly to wl_buffer, flush all cached drawings we have or clear them if there's fullscreen
    update.

Attachment #9092335 - Attachment description: Bug 1580152 - [Wayland] Flush cached drawings in frame callback, r=jhorak → Bug 1580152 - [Wayland] Fix rendering glitches on wayland , r?jhorak

I think Fedora's openQA tests are hitting something like this too, in fact. Since Firefox 69 appeared we've been seeing failures like this:

https://openqa.fedoraproject.org/tests/443437#step/desktop_browser/7

that should be a correct rendering of https://admin.fedoraproject.org/accounts/ , but obviously...isn't. In this test, though, openQA isn't flicking between already-loaded tabs - it starts the browser, opens a new tab, then opens that URL, and when the page loads this mis-rendering is seen. Still the same bug?

You can see a video of the failure happening at https://openqa.fedoraproject.org/tests/443437/file/video.ogv - skip to about 0:40.

  • Don't store whole buffer update information at mWholeWindowBufferDamage but use damage region instead.
  • Check and remove overlapped images when they are stored at image cache.
  • Remove CanDrawToWaylandBufferDirectly() as it's not very useful.
Attachment #9093255 - Attachment is obsolete: true

Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/404cd5ce8054
[Wayland] Fix rendering glitches on wayland , r=jhorak

Keywords: checkin-needed

Martin, I installed the firefox-69.0-7.fc31 build you did today and it does seem to fix this, on my local system at least. Not sure if it fixes the openQA issue yet (it'll be easier to tell when it's submitted as an update). Thanks!

https://hg.mozilla.org/mozilla-central/rev/404cd5ce8054

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox71: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Comment on attachment 9092335 [details]
Bug 1580152 - [Wayland] Fix rendering glitches on wayland , r?jhorak

Beta/Release Uplift Approval Request

  • User impact if declined: Page/tab switch may update only part of the screen on Wayland.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Linux/Wayland only.
  • String changes made/needed: none
Attachment #9092335 - Flags: approval-mozilla-beta?

Has the fix been verified in Nightly?: No

I just tested Nightly version "71.0a1 (2019-09-18) (64 bits)". It seems to include the fix since I was unable to reproduce the bug with this binary!

Comment on attachment 9092335 [details]
Bug 1580152 - [Wayland] Fix rendering glitches on wayland , r?jhorak

Wayland fix, approved for 70.0b8.

Attachment #9092335 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: