Created attachment 8903935 [details] gmail ff57.0a1.png User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170902100317 Steps to reproduce: 1. Open FF 56 or 57 with one of my profiles that has set (many) tabs to re-open. 2. FF opens, tabs reopen, pinned tabs start to load. Actual results: 3. Sometimes (not always) pinned tabs that load Gmail or Google Drive or Google Calendar or Yahoo Mail don't display completely. For example, buttons are missing, or mail list is missing. Attachment shows Gmail. 3a. If I reload the page (or CTRL reload), it will load the same (broken) way. 3b. If I move my mouse over the missing elements, some will display. On mouse move some will stay visible, some will hide again. Expected results: The contents of web sites should load and be displayed fully. This has started to happen around FF 56.0b3 (64-bit). It is present since then, including 56.0b8 and 57.0a1. I have installed FF 55 and it works fine. Workaround 1: Use older version of FF. Workaround 2: Close and reopen FF. Some other tabs will behave wrong way so I can use the tab I want. Repeat several times to get the desired tab.
Usually this kind of issues are caused by rogue graphics drivers. Please update yours: https://support.mozilla.org/kb/upgrade-graphics-drivers-use-hardware-acceleration
Component: Untriaged → Graphics
Product: Firefox → Core
Hello, thanks for your answer and your help. I have updated my graphic drivers and so far it seems it has fixed the issue. I'll report here if the issue comes back after some time of use. Thanks!
Updating graphic drivers was not the solution for the issue. After running FF (and my computer) for some time the issue came back in the same way. Any other ideas?
It's still happening with 57.0a1 (2017-09-08) (64-bit). I have noticed additional info on the behaviour of this issue. As noted before, if I reload (or CTRL reload) a tab with broken design, it will never load correctly. However, if I copy the link, open a new tab and load the link in the new tab, there's a good chance the site will load with a complete design. It doesn't always happen, but in 75% of cases it does. It makes me think it's not about a broken graphic driver, but maybe about what happens when tabs are loaded, especially if they are loaded simultaneously (like pinned tabs). This never happens in FF 55 using the same FF profile on the same machine.
Does it now *only* happen on Firefox 57, or is it still reproducible on 56? Could you attach a copy of your about:support from the earliest version that has the problem?
Created attachment 8906729 [details] raw.txt Troubleshooting Information I have tested it with Firefox 56.0b10 (64-bit) and it is still reproducible. I'm attaching raw troubleshooting info in the attachment. Additional info: I am using Firefox 57 on another machine ant I haven't noticed this behaviour. On that machine everything loads and displays as expected.
Are you running multi-content-process? What's the value for Multiprocess Windows in Application Basics in about:support.
status-firefox56: --- → affected
status-firefox57: --- → affected
Priority: -- → P2
A mozregression  result to narrow down when this started would be really helpful.  http://mozilla.github.io/mozregression/install.html, http://mozilla.github.io/mozregression/quickstart.html
Priority: P2 → P1
Yes, I'm running multi-process: Večprocesna okna 1/1 (Omogočil uporabnik) Procesi spletne vsebine 6/5 I'll try Mozregression now.
I can't run Mozregression, the process doesn't start. Since I have updated the graphic driver I have problems with Windows 10. I think I'll have to set up Windows again before I can try, sorry.
I have looked at comments in bug 1396278 (that is connected to bug 1387544) and it might be that this is duplicate of that bug. The behaviour is the same: parts of page don't display, it happens only on some pages and only in some tabs, if the same URL is opened in another tab it will eventually load correctly, parts of content displays on moving the mouse, the issue started appearing somewhere in the middle of FF56. I have tried turning hardware acceleration off and so far I haven't seen this behaviour again.
Sorry, the bug with more info that this could be a duplicate of is bug 1381668.
If it's individual images that are disappearing, it may very well be bug 1380649
See Also: → bug 1380649
Milan, can be. But I'm missing images, text, checkboxes, backgrounds, whole blocks... Not just individual images.
I reinstalled Windows and unfortunately lost my Firefox account. However, the bug is still persistent. I'll get on with Mozregression.
I tried it from Aug 21 2017 and all the builds were bad. What should I choose with "Build type" and "Repository" to get beta or nightly builds? If I chose mozilla-beta or mozilla-aurora there were no builds available. With default settings all builds were bad. I want to go further back but also need to get the settings right first. I was using the same profile with many tabs where the problems arose. I'm not sure if I can replicate with a blank profile because I think I'd first need to load many tabs (and maybe pin them) to see the behaviour.
Thanks Miha! When running mozregression, just leave the basic configuration at default (e.g., if running windows 64-bit, it would say firefox/64/opt (the build type is just opt) Same thing for the profile selection - leave at default, which will give you a new profile. On the last dialog, the default is to go back a year - since we don't know when this started, this is not a bad idea.
I have done Mozregression. I'm not sure what to report here, but this is how the log finishes after testing 15 builds: 2017-10-02T22:51:47: INFO : Narrowed inbound regression window from [c1185e61, b74b71ee] (3 builds) to [c1185e61, dd4e52e8] (2 builds) (~1 steps left) 2017-10-02T22:51:48: DEBUG : Starting merge handling... 2017-10-02T22:51:48: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=dd4e52e83896d64b66adc8a303a2b49cec93d880&full=1 2017-10-02T22:51:49: DEBUG : Found commit message: Bug 1380268 - Let the new search textbox styling graduate from in-content/common.inc.css to textbox.css. r=nhnt11 MozReview-Commit-ID: It4s0dWvKkl 2017-10-02T22:51:49: INFO : The bisection is done. 2017-10-02T22:51:49: INFO : Stopped Is this helpful of you need more info?
Miha, extremely helpful, thanks a lot! Dao, looks like a theme related regression from bug 1380268. Possibly causing bug 1387544 as well.
Assignee: nobody → dao+bmo
tracking-firefox57: --- → ?
(In reply to Milan Sreckovic [:milan] from comment #19) > Miha, extremely helpful, thanks a lot! > > Dao, looks like a theme related regression from bug 1380268. Possibly > causing bug 1387544 as well. This doesn't make sense. Bug 1380268 is about <xul:textbox type="search"/>, it can't affect web content.
Assignee: dao+bmo → nobody
The symptoms look pretty much as bug 1381668 to me.
Tracking in bug 1381668, let's track this one too for now until we confirm they're the same.
status-firefox56: affected → wontfix
status-firefox58: --- → ?
status-firefox-esr52: --- → unaffected
tracking-firefox57: ? → +
Matching flags to bug 1381668.
status-firefox57: affected → fix-optional
Priority: P1 → P2
You need to log in before you can comment on or make changes to this bug.