website text randomly disappears

RESOLVED WORKSFORME

Status

()

Core
Graphics: Text
RESOLVED WORKSFORME
a year ago
4 months ago

People

(Reporter: alef.data, Unassigned)

Tracking

({regressionwindow-wanted})

47 Branch
Unspecified
Linux
regressionwindow-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8774011 [details]
Screenshot - 230716 - 04:01:20.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160629103935

Steps to reproduce:

While browsing some web pages, problems appears randomly.

Started in Firefox 46 or 47 in debian linux.


Actual results:

all text of the page disappears after page load, or focus on the tab.


Expected results:

page text should be visible

Comment 1

a year ago
Graphics issues probably.

Could you type about:config in the location bar and set gfx.xrender.enabled to true (restart Firefox to apply) and test.
Component: Untriaged → Graphics: Text
Flags: needinfo?(alef.data)
Product: Firefox → Core
(Reporter)

Comment 2

a year ago
@Loic thanks.

gfx.xrender.enabled was already set to true. I tried false, the problem reoccured again.
Flags: needinfo?(alef.data)

Comment 3

a year ago
Do you have HWA enabled?
https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-acceleration

In addition, if the issue appeared with FF46, could you install the tool Mozregression to narrow down a regression range, please.

See http://mozilla.github.io/mozregression/ for details.
Run the command "mozregression --good=45" then copy here the final pushlog provided in the console output.
Flags: needinfo?(alef.data)
Keywords: regressionwindow-wanted
Whiteboard: [gfx-noted]

Comment 4

a year ago
Alef, could you test what I wrote in comment #3, please. If you can find a regression range, it would help a lot.
(Reporter)

Comment 5

a year ago
Hi Loic,

Thanks for the follow-up.

I'm currently testing with the hardware acceleration disabled. The bug only shows up from time to time, so I'll wait a few more days to confirm whether it actually disappeared, if that's ok.

Regarding mozregression, I had issues installing it, probably something related to python, so I gave up:


>    $ sudo pip2 install -U mozregression
>    [...]
> File "/usr/lib/python2.7/codecs.py", line 296, in decode
>    (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xb6 in position 147: invalid start byte in /usr/lib/pymodules/python2.7/rpl-1.5.5.egg-info

Comment 6

a year ago
About the python issue, it's probably a character encoding issue is the file rpl-1.5.5.egg-info, open it and replace character like "รถ" which can not be read by "o".
(Reporter)

Comment 7

a year ago
Here's an update:

* testing with hardware acceleration disabled: the issue reproduced once again, with hardware acceleration disabled - now on Firefox 48.0.

* using mozRegression
  * managed to install thanks to the correction you recommended
  * didn't use it yet. Fact is that the bug only appears from time to time, like once every two weeks. Seems to me like using mozregression in this situaion would require months of continuous usage. Is what I'm writing here making sense?

Comment 8

a year ago
Yes, if the issue is really sporadic, it will be hard to use mozregression, because this tool downloads nighly builds, so in general, you have to test them immediately to know if they are good or bad.

Comment 9

a year ago
Lee, could you NI? someone from the graphics team who could help the OP to narrow down the issue and maybe the regression.
Flags: needinfo?(lsalzman)
OS: Unspecified → Linux
(In reply to alef.data from comment #7)
> Here's an update:
> 
> * testing with hardware acceleration disabled: the issue reproduced once
> again, with hardware acceleration disabled - now on Firefox 48.0.
> 
> * using mozRegression
>   * managed to install thanks to the correction you recommended
>   * didn't use it yet. Fact is that the bug only appears from time to time,
> like once every two weeks. Seems to me like using mozregression in this
> situaion would require months of continuous usage. Is what I'm writing here
> making sense?

Can you go to the about:support page and paste the "Graphics" section there?
Flags: needinfo?(lsalzman)
When you hit this bug - does switching tabs get the correct page back?  What about resizing or scrolling?
(Reporter)

Comment 12

a year ago
> Can you go to the about:support page and paste the "Graphics" section there?

Here you go:

Graphics
--------

Features
Compositing: Basic
Asynchronous Pan/Zoom: none
WebGL Renderer: Intel Open Source Technology Center -- Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Hardware H264 Decoding: No
GPU #1
Active: Yes
Description: Intel Open Source Technology Center -- Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Vendor ID: Intel Open Source Technology Center
Device ID: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
Driver Version: 3.0 Mesa 10.3.2

Diagnostics
AzureCanvasAccelerated: 0

AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
CairoUseXRender: 1

> When you hit this bug - does switching tabs get the correct page back?  What about resizing or scrolling?

I'll double-check whenever the problem comes back.
(Reporter)

Comment 13

a year ago
> When you hit this bug - does switching tabs get the correct page back?  What about resizing or scrolling?

I have just managed to reproduce the bug. Neither scrolling nor resizing the window have an effect on the problem.

Howeve, when switching to another tab then coming back, I noticed the correct page being displayed for like half a second, then being the whole page's content being resized and the text disappearing.

This made me realize that this issue is caused by the "autoHiDpi" addon, which does not behave properly when pages are zoomed in (using firefox' zooming function).

I tested with the addon disabled, and the problem stopped happening (apparently).

What autoHiDpi does is to vary the "devPixelsPerPx" option's value based on the window size reported by Firefox. Firefox is not always consistent in reporting the window size, especially when zoom is used.

Perhaps this bug report should be closed, as it's more related to the addon? 

Sory if I wasted your time, and thanks for the provided support.

Updated

a year ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
(Reporter)

Updated

4 months ago
Flags: needinfo?(alef.data)
You need to log in before you can comment on or make changes to this bug.