Closed Bug 1279677 Opened 8 years ago Closed 8 years ago

Some UI animations (like Download arrow or Bookmark star icon) remain partially on screen with Firefox 47.0

Categories

(Core :: DOM: Animation, defect)

Product:
Core
Component:
DOM: Animation
Version:
47 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox47 --- wontfix
firefox48 + wontfix
firefox49 + fixed
firefox50 + fixed

People

(Reporter: c31948, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [gfx-noted])

Attachments

(2 files)

download_icon.png
4.30 KB, image/png
Details
Picture showing the download arrow artefact on Windows 10
9.52 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Downloaded something.  


Actual results:

Arrow didn't entirely clear.


Expected results:

The arrow should have cleared.
The only solution seems to be to restart Firefox.
Can you attach a screenshot Peter ?
In addition, type about:support in the location bar and copy the "graphics" section.
Flags: needinfo?(c31948)
I'm unable to do that at the present time.

Problem occurred immediately after running latest version of Firefox.

It's just vestiges of blue above and below the highlighted blue down arrow.

It's not fully clearing.
In bug 1279794, a user has the same issue. He said testing with a fresh profile doesn't exhibit the issue.
Could you test, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

In addition, type about:support in the location bar and copy here the full page of info.
See Also: → 1279794
Attached image download_icon.png — 
This is not reproducible all the time, but is really a irritating issue.
Found this on my 47.0 but not on nightly 49.0a1
May be related to core->graphics ?

Here is my about:support | grahpics  ==

Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) G41
Asynchronous Pan/Zoom	none
Device ID	Mesa DRI Intel(R) G41
Driver Version	2.1 Mesa 11.0.2
GPU Accelerated Windows	0/1 Basic (OMTC)
Supports Hardware H264 Decoding	No
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) G41
windowLayerManagerRemote	true
AzureCanvasAccelerated	0
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0
Component: Untriaged → Downloads Panel
Summary: Download arrow remains partially on screen. Ver 47.0 → Download arrow animation remains partially on screen with Firefox 47.0
Many reports about this issue since FF47, I set flags to track it.
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
tracking-firefox48: --- → ?
tracking-firefox49: --- → ?
tracking-firefox50: --- → ?
Keywords: regression, regressionwindow-wanted
OS: Unspecified → All
Hardware: Unspecified → All
My about:support graphics section (german, unfortunately):

Asynchrones Wischen und Zoomen		nichts
Direct2D aktiviert			true
DirectWrite aktiviert			true (10.0.10586.0)
Gerätekennung				0x0126
GPU #2 aktiv				false
GPU-beschleunigte Fenster		0/1 Basic
H264-Hardware-Dekodierung unterstĂĽtzt	No; Unsupported layers backend
Herstellerkennung			0x8086
Karten-Beschreibung			Intel(R) HD Graphics 3000
Karten-RAM				Unknown
Karten-Treiber				igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Subsys-ID				21ce17aa
Treiber-Datum				5-27-2015
Treiber-Version				9.17.10.4229
WebGL-Renderer				Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote		false
AzureCanvasAccelerated			0
AzureCanvasBackend			direct2d 1.1
AzureContentBackend			direct2d 1.1
AzureFallbackCanvasBackend		cairo
I am seeing this on Fedora 24, Firefox 47.0, ThinkPad T450s. Will try to catch a screenshot the next time it happens; it's not consistent in it's ability to be reproduced.
In fact, we have enough screenshots of the evidence of the issue. But it would be helpful to find a regression range with the tool Mozregression (see http://mozilla.github.io/mozregression/ for details).
The tool downloads nightly builds and you can enter if the nightly is bad or good.

As FF46 doesn't have the bug, you can start with the command "mozregression --good=46" (or 45) then copy here the final pushlog from mozilla-inbound repository.

I guess you'll need to repeat the test many times with each nightly if the issue is not reproducible consistently.

I checked some "graphics" reports and many systems are affected (Windows, Linux, Intel, Nvidia).
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is not a critical issue that needs to be included in a dot release.
status-firefox47: affected → wontfix
In all the screenshots I saw, the download arrow is in the navbar. As someone has reproduced the issue in safe mode, I doubt some add-ons are faulty.
Hi, same problem here. I run Linux Mint 17.3 and I have Firefox 47.0

A way to get rid of the arrow is to un-maximize (sorry don't know the word, but it's not minimize!); then if you maximize the window again the problem is solved.

Cheers!

PS: If I can provide extra information that could be useful that hasn't been posted here I would be happy to do it.
(In reply to Paulo from comment #16)
> PS: If I can provide extra information that could be useful that hasn't been
> posted here I would be happy to do it.

Yes, you can! :)
See https://bugzilla.mozilla.org/show_bug.cgi?id=1279677#c12
Thanks,

Hi this is the output:
2016-06-29T19:57:30: INFO : Running mozilla-central build for 2016-01-25
2016-06-29T19:57:40: INFO : Launching /tmp/tmpwI78cq/firefox/firefox
2016-06-29T19:57:40: INFO : application_buildid: 20160125060632
2016-06-29T19:57:40: INFO : application_changeset: 3f41d7d0f544ebd98273e39bd945c28878a47427
2016-06-29T19:57:40: INFO : application_display_name: Nightly
2016-06-29T19:57:40: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2016-06-29T19:57:40: INFO : application_name: Firefox
2016-06-29T19:57:40: INFO : application_remotingname: firefox
2016-06-29T19:57:40: INFO : application_repository: https://hg.mozilla.org/mozilla-central
2016-06-29T19:57:40: INFO : application_vendor: Mozilla
2016-06-29T19:57:40: INFO : application_version: 47.0a1
2016-06-29T19:57:40: INFO : platform_buildid: 20160125060632
2016-06-29T19:57:40: INFO : platform_changeset: 3f41d7d0f544ebd98273e39bd945c28878a47427
2016-06-29T19:57:40: INFO : platform_repository: https://hg.mozilla.org/mozilla-central
2016-06-29T19:57:40: INFO : platform_version: 47.0a1
2016-06-29T19:57:42: INFO : 
2016-06-29T19:57:42: INFO : (process:8216): GLib-CRITICAL **: g_path_get_basename: assertion 'file_name != NULL' failed

I hope this helps, if I did something wrong, I can try it again ;)
Ah, and this was the other output:

app_name: firefox
build_date: 2016-01-25
build_file: /home/user/.mozilla/mozregression/persist/2016-01-25--mozilla-central--firefox-47.0a1.en-US.linux-x86_64.tar.bz2
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2016/01/2016-01-25-06-06-32-mozilla-central/firefox-47.0a1.en-US.linux-x86_64.tar.bz2
changeset: 3f41d7d0f544ebd98273e39bd945c28878a47427
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central
There was an issue with mozregression, you should obtain a pushlog like https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=63cc176d76a66b1807ea4b9500651063032123b1&tochange=d24b11e4beb29e7b0941121b93b10fc155c53a4e at the end of the run.

At each step, Mozregression launches a build and you have to do the test (downloading a file here) and enter if the build is bad or good.
Track this as this is a regression issue.
tracking-firefox48: ? → +
tracking-firefox49: ? → +
tracking-firefox50: ? → +
Windows 10, 64bit, I have HWA switched off (I'll switch it on now).
This looks like an invalidation problem. Pretty nasty. Hey jrmuizel, do you know if something changed in the graphics layer in 47 that might cause this kind of invalidation bug?
Flags: needinfo?(jmuizelaar)
Nothing jumps to mind. As suggested above the regression window would help a lot.
Flags: needinfo?(jmuizelaar)
The Bug survives resetting Firefox (I believe that creates a new profile).
The two png files provided by others (thank you) accurately depict the Bug.
Hey RyanVM, do you know if SV folk have cycles to try to help us find a regression window here?
Flags: needinfo?(ryanvm)
About;support Graphics section:-

Adapter Description	Intel(R) 82945G Express Chipset Family
Adapter Drivers	ialmrnt5
Adapter RAM	Unknown
Asynchronous Pan/Zoom	none
Device ID	0x2772
Direct2D Enabled	Blocked for your graphics driver version. Try updating your graphics driver to version 6.1400.1000.5218 or newer.
DirectWrite Enabled	false (0.0.0.0)
Driver Date	4-5-2005
Driver Version	6.14.10.4299
GPU #2 Active	false
GPU Accelerated Windows	0/1 Basic (OMTC) Blocked for your graphics driver version. Try updating your graphics driver to version 6.1400.1000.5218 or newer.
Subsys ID	01ad1028
Supports Hardware H264 Decoding	No; Failed to create H264 decoder
Vendor ID	0x8086
WebGL Renderer	Blocked for your graphics driver version. Try updating your graphics driver to version 6.1400.1000.5218 or newer.
windowLayerManagerRemote	true
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
Flags: needinfo?(ryanvm) → needinfo?(mfunches)
Everyone that's hitting it appears to be on Basic layers. Probably worth paying attention to.
Hi I ran the regression, and the nightly versions didn't seem to have the problem (I run from 2015 to 2016 10th as the interval. The program checked the extremes and when having downloaded a file the problem didn't showed up.

My Linux installation is a fresh one (less than two weeks from now), so I believe also very recent builds have the problem (the current installation does) and a way to remove the remnant arrow is to unmaximize and maximize again the window.
I ran mozregression also (see duplicate bug), but likewise I was not able to determine a point in time...
If it appears only with HWA disabled or missing (blocked drivers, disabled manually, etc), you have to create a new profile with HWA disabled (in advanced options) then use it with mozreg by using the command "--profile /path/to/profile --profile-persistence reuse".
QA Update: Could  not reproduce to the extend reported on Windows 10 or Windows XP - however I do see lagging in redraw on Win10 when I downloaded this PDF https://static.googleusercontent.com/media/www.google.com/en/us/help/hc/images/android/android_ug_50/Android-Lollipop-Quick-Start-Guide.pdf
GPU Accelerated Windows	0/2 Basic (OMTC)
Multiprocess Windows 	2/2 (Enabled by user) and also tested Disabled
Use hardware acceleration when available tested unchecked
Flags: needinfo?(mfunches)
(In reply to Loic from comment #35)
> ... it appears only with HWA disabled ...
Confirmed, no more graphic artefacts after switching HWA back on.
Jork, do you have some time to run Mozregression with a custom profile where HWA is disabled?
Flags: needinfo?(mozilla)
Sorry, I don't. You can try Alice.

BTW, I running this on a laptop with Windows 10 64bit and Intel HD Graphics 4000.
Flags: needinfo?(mozilla) → needinfo?(alice0775)
This is a recent-enough regression that I would think |mozregression --pref "layers.acceleration.disabled:true"| would work instead of having to play games with profiles? I have access to a similar laptop as comment 39, so I may give it a go later tonight.
I am not able to reproduce...
Flags: needinfo?(alice0775)
Star icon when bookmarking is affected too, so it's more an issue about graphics and invalidation.
Component: Downloads Panel → Graphics
Product: Firefox → Core
Maybe the title of this bug should be changed to something more descriptive as we now know that it is more of a general graphics issue rather than just affecting the downloads graphic. For instance something like what I titled mine: "Firefox 47 does not clear graphics properly in Toolbar".
Summary: Download arrow animation remains partially on screen with Firefox 47.0 → Some UI animations (like Download arrow or Bookmark star icon) remain partially on screen with Firefox 47.0
Anthony, can you reproduce this (with acceleration off)?
Flags: needinfo?(anthony.s.hughes)
Whiteboard: [gfx-noted]
I saw this on my Mac with Nightly a few days ago, however I only saw it once. I'll run with acceleration off for a while to see if it returns.
Flags: needinfo?(anthony.s.hughes)
hiro, this issue seems to be similar to bug 1265605.
Do you think it's fixed by your patch in bug 1258904?
Flags: needinfo?(c31948) → needinfo?(hiikezoe)
Very likely.  
It would be appreciated if someone, who can easily reproduce this issue, confirm the fix range.
Flags: needinfo?(hiikezoe)
Confirmation: looks good to me on Nightly XP, Win10, Fedora, please "ni" if there is need to test on other Channels etc 
Version 	50.0a1
Build ID 	20160722030235
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:50.0) 
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) 
User Agent      Mozilla/5.0 (X11; Linux i686; rv:50)
Flags: needinfo?(hiikezoe)
Thank you, Michelle.  Now I'd like to know which bug exactly fixed this issue.  Then we can mark this issue as a dupplicate of it.  If it's bug 1258904, below might reduce the effort to find it.

./mach mozregression --find-fix --good 2016-05-10 --bad 2016-05-07

Thank you,
Flags: needinfo?(hiikezoe) → needinfo?(mfunches)
zavarzin, are you able to reproduce it with FF49 as asked in comment #51?
https://www.mozilla.org/en-US/firefox/developer/all/
Flags: needinfo?(zavarzin)
status-firefox48: affected → wontfix
Component: Graphics → DOM: Animation
OK, this bug seems to be solved in FF49 and CAN'T be reproduced.

Also I just noticed that it is only reproducible with the Hardware Acceleration DISABLED in FF47.
I just ENABLED Hardware Acceleration in FF47 and the issue has gone.
To it happens, in FF27, with hardware acceleration enabled, although it doesn't happen with any file to download. It happened to me with PIA's new linux installer, but not with some pdfs from Jstor.
QA Update for MozRegression:
 7:47.14 LOG: MainThread Bisector INFO First good revision: 0ecd7d72f232304da046
b352c457e039e35ceed7
 7:47.14 LOG: MainThread Bisector INFO Last bad revision: 211a4c710fb6af2cad1010
2c4cabc7cb525998b8
 7:47.14 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=211a4c710fb6af2cad
10102c4cabc7cb525998b8&tochange=0ecd7d72f232304da046b352c457e039e35ceed7
Flags: needinfo?(mfunches)
Michelle helped me understand the current situation.  It seems the mozregression gave us the range in comment 56 as when this problem was originally fixed.  That range is in 47, and we experience the problem in 47, so sometime after this range, the bug showed up again, shipped in 47, then eventually got fixed in 49.
Sounds like we should mark this fixed.
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49: affected → fixed
status-firefox50: affected → fixed
Resolution: --- → FIXED
Appears fixed in 48.0 
Thank you
Sorry, I spoke too soon. The bug is NOT FIXED IN 48.0. 
On various downloads of images especially the arrow doesn't clear.
(In reply to Peter from comment #61)
> Sorry, I spoke too soon. The bug is NOT FIXED IN 48.0. 
> On various downloads of images especially the arrow doesn't clear.

This current bug is probably fixed by 1258904 which is in 49+.
Flags: needinfo?(zavarzin)
Confirmed, the bug is still present in FF48 (Mint 18), waiting for the 49 version :D
(In reply to Paulo from comment #63)
> Confirmed, the bug is still present in FF48 (Mint 18), waiting for the 49
> version :D

You can download it here https://www.mozilla.org/en-US/firefox/beta/all/ if you want.
The bug is still there in the recently provided version 48.0.1
Per comments 58 and 62, this isn't expected to be fixed until 49 ships next month.
Version 48.0.2 seems to fix it for me. I hope I've not spoken too soon.
I did speak too soon. 48.0.2  
After a few days the problem returned !!!
We already said the fix was only in 49+.
Thank you.
I am really new to bugzilla and i reported this bug yesterday, today morning i got email link to this bug as it was already reported by Peter. I just want to know why it can't be fixed for Firefox 47.0 ??
That's because I did hesitate to uplift the fix to 47 branch without a proper test case for this bug.  Actually I unintentionally fixed this bug in bug 1258904.
At this time of Firefox 49, you cannot even do that.
Ah, right.  When I did notice this, firefox 47 had been already release, I had a chance to uplift 48, but didn't.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: