781414 - Excessive Repainting when certain extensions are enabled on the addon bar and zoomed in. (MemChaser, StatusbarEX) [Possibly only affecting users with a lot of system memory]

Status: VERIFIED WORKSFORME

(Core :: Graphics, defect)

Description

[Danial Horton]

User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120808030529

Steps to reproduce:

Scrolling long webpages, especially while zoomed in is far choppier under Nightly 17 in comparison to Aurora 16

The problem gets worse for those not using hardware acceleration in firefox, but while accelerated it is still somewhat choppier


Actual results:

Browsing the attached url, particularly while zoomed in to 1.33x (Ctrl-+ 3x) and then scrolling the page will be noticeable choppier under 17 than it is under 16


Expected results:

Comparable smoothness between both browsers

Comment 1

[Danial Horton]

Suspected: Bug 773100

Comment 2

[Danial Horton]

actually, i think neither this or the scrollbar issue are caused by 773100 since 773100 has landed on aurora and the same problems are not present

Comment 3

[Danial Horton]

going to grab some MI builds and see whats what here.... clearly since 773100 is now on aurora it can't be the cause.

Comment 4

[Danial Horton]

anyone know where i can get inbound builds from between the 21st and the 28th of july?

Comment 5

[Danial Horton]

ok, i think things started to get choppier with 20120727030508, its there, barely, i can feel it atleast

it was the build on the 30th where i saw the scrollbar start to hang and the browser get really choppy though, and i just finished downloading nightly 28 and 29 so....

Comment 6

[Danial Horton]

MC

Smooth(er)
20120727030508
http://hg.mozilla.org/mozilla-central/rev/8b96a33ecbd2

Choppy as all heck
20120728030524
http://hg.mozilla.org/mozilla-central/rev/2abd21593e57

Comment 7

[Danial Horton]

Suspect: Bug 777264

Comment 8

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b96a33ecbd2&tochange=2abd21593e57

I can't distinguish any difference with X11 either with a GPU accelerated server or with a tigervnc software framebuffer.

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to Danial Horton from comment #4)
> anyone know where i can get inbound builds from between the 21st and the
> 28th of july?

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/

Comment 10

[Danial Horton]

Figured as much

and yeah, its looking to be windows only.

Comment 11

[Karl Tomlinson (:karlt)]

Bug 778701 comment 9 gives this regression range:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4bfa8a24fe41&tochange=5fe4c57fb73e

Comment 12

[Danial Horton]

this is looking to be a pain to get the range on..

and i was right,  builds after the 27th exacerbate the problem further

its just barely noticeable on builds prior to the 27th

I have found that it is somewhat related to extensions that have an updating counter or ui item like statusbarex or status-4-eva.

Comment 13

[Danial Horton]

I should clarify my reproduction steps

Fresh Profile
Install StatusbarEx (or another extension with a  continually changing gui item)
navigate to the site mentioned above and zoom in to 1.33 (ctrl-+ 3x)

The difference in the following regression range is barely noticed, just watch the text on the page closely and you should see far more flickering as the page scrolls with the affected builds.

Tinderbox-MI
Good
20120722180322
http://hg.mozilla.org/integration/mozilla-inbound/rev/c07793b7dc10

Bad
20120722210121
http://hg.mozilla.org/integration/mozilla-inbound/rev/058d3e6887cd

Tinderbox builds after the 27th get even worse, with visibly hitching while scrolling

Sorry my ranging has been all over the place,  i initially did not notice the text flicker until i looked closer.

Should i determine the tinderbox Central range as well?

Comment 14

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c07793b7dc10&tochange=058d3e6887cd

No need to look at m-c builds.

Bug 776226 should affect only Mobile builds.
Bug 741682 seems more likely.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 741682 should have affected all platforms, should have no effect on scrolling with accelerated layers, and should have no effect on most pages ... which doesn't match this bug's description very well. Needs investigation...

Comment 16

[Danial Horton]

i've currently gone back to aurora builds as using nightly builds over a period of time becomes completely impossible. 

At that point, its not just scrolling which has gone to hell, you can't even type into the facebook or google searchboxes as the page takes far too long to repaint with the new changes.

I didn't even have to test it on my usual profile, yesterday all i was doing was visiting whirlpool, mozillazine and bugzilla in the  new profile, and eventually it was hitching so bad....

Just for reference,  the use of statusbarex is just an extension i found to force the issue out.  It does eventually appear with browsing a tab heavy session even without extensions like it.

The source code for 0.3.5 is at https://code.google.com/p/statusbarex/source/browse/?r=44 for anyone wanting to check and see if its an extension fault.

R45 is not for use, i was only able to get a version of it running in an nightly version of Firefox 9?... or was it 10, either way, yeah thats not for use.

Comment 17

[Danial Horton]

just tested the latest nightly in the same site/extension/zoom level and the hitching is gone

its back to the smoothness i observed in 20120722210121 which is still worse than 20120722180322 and Aurora

Comment 18

[Danial Horton]

I noticed while trying to re-range a different bug that some more MI Tinderbox builds had appeared in the folder, i was going to see if i could narrow it down further but the PGO folder doesn't go older than 20120722210121 anymore

20120722210121
http://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/1343016081/

however in the folder without pgo in the name, there is 20120722192842 so i can see if that is good or bad.

Comment 19

[Danial Horton]

TinderBox MI

Smooth
20120722192842
http://hg.mozilla.org/integration/mozilla-inbound/rev/9302468f64fa

Not visually smooth
20120722210121
http://hg.mozilla.org/integration/mozilla-inbound/rev/058d3e6887cd

Can someone provide builds between these changes for me to try?, not at a machine capable of building them myself atm.

Comment 20

[Timothy Nikkel (:tnikkel)]

Comment 19 gives a regression range of
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9302468f64fa&tochange=058d3e6887cd

I don't know if bisecting it anymore would be helpful.

Comment 21

[Danial Horton]

:< issue followed 17 to aurora, not that i thought it wouldn't

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Over to Matt to investigate http://www.chia-anime.com/alpha/K to see if there's anything we can do to unregress it.

Comment 23

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this on unaccelerated OSX10.7.

There doesn't appear to be anything fixed position that would trigger component alpha flatenning.

Comment 24

[Alex Keybl [:akeybl]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #23)
> I can't reproduce this on unaccelerated OSX10.7.
> 
> There doesn't appear to be anything fixed position that would trigger
> component alpha flatenning.

Adding qawanted to see if we're able to reproduce on any of the configurations in our lab, so that Matt can take a look at an affected config.

Comment 25

[u279076]

Marcia, can you take a crack at this in our QA Lab?

Comment 26

[Marcia Knous [:marcia]]

Following the STR in Comment 13 I am not seeing any issues using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 on my primary Win 7 machine. Will check trunk as well, and I have one other Win 7 configuration in the lab I can check ATM.

Comment 27

[Danial Horton]

be sure to compare it against beta side by side with the same extension.

If you watch the text on the page you'll see it just isn't scrolling as smoothly in 17 as 16 does.

if you still can't see it,  increase the dpi to 120ppi, it was a bit harder to see at 96ppi on the XP VM i did some follow up tests on, but it was there.

Comment 28

[u279076]

Marcia, can you give a status update on your testing of this bug?

Comment 29

[Marcia Knous [:marcia]]

No update yet - yesterday when I went down to the QA lab Clint was setting up something on the Windows 7 machine. I will try again when I am back in the office.

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

Starting to get closer to Beta so feedback on this prior to merge on 9/27 would be great so we have time to look for possible backouts.

Comment 31

[Karl Tomlinson (:karlt)]

Danial, would you be able to check whether bug 786978 addressed this on Aurora, please?

Comment 32

[Danial Horton]

hmm, its worse then when i last tested it.

but theres a slight difference in its behavior now.
If i resize the window smaller it gets smoother in relation to the size of the window.

Having the window maximised, its not so much as hitching as its like a ghosted image now.  I would almost blame my display if it were not for the fact its still completely unreproducable in Beta(16)

Comment 33

[Marcia Knous [:marcia]]

Danial: Can you please let us know exactly which build IDs you were testing with?

Comment 34

[Danial Horton]

i grabbed the latest at the time
so, http://hg.mozilla.org/releases/mozilla-aurora/rev/3440e0b0cdb3

updating again now

Comment 35

[Danial Horton]

alright, tried the latest, and its smooth while scrolling.... until i click the maximise  button or double click the title bar to maximise and then it all goes to heck again :(

I managed to get the behavior on a recording, so i'll try posting a video of it.

Comment 36

[Danial Horton]

http://youtu.be/yTflrtYzz8c

watch it in 1080p

Comment 37

[Marcia Knous [:marcia]]

I tried this again on two different machines, one running Win 7 and the other running Windows 8.

Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 which is the latest build, as well as the latest beta, I wasn't able to discern a difference in scrolling on that page.

Comment 38

[Danial Horton]

You do have layers.acceleration.disabled;true, right?

i can definitely say the issue is no longer present when accelerated, but its definitely there as  soon as you set layers.acceleration.disabled;true, restart and maximise the window

i've got several different laptops i have verified this with, different graphics chips and drivers, mines the only one with 120dpi set, but i've removed that as a factor having experienced it on the other systems.

Comment 39

[Danial Horton]

I had a friend with a larger screen than i test, and he does seem to experience scrolling is slower when maximised.

His screen is much larger than mine though, so he may already be experiencing the issue worse than I am, so the test may be skewed.

Testing further, i see that when the window is resized to fill a 1024x768 lcd screen (unmaximised!) the scrolling is fluid. When i maximise the window on that display, scrolling is hitchy and juddery
When i unmaximise again it returns to being smooth.

Returning the window to the larger screen, it continues to remain smooth till it reaches an impossible to specify window dimension, where the stutters again return.

If i dock the window to the sides so that it only takes up half the screen, it is smooth until i maximise and unmaximise, which then the hitching occurs in this position.

This is obviously some bug in the software back end, that only seems to rear its head under a difficult to replicate circumstance.

Comment 40

[u279076]

1. Installed Firefox 16.0b6
2. Set layers.acceleration.disabled;true
3. Loaded http://www.chia-anime.com/alpha/K
4. Maximize the window
> Scrolling is smooth, no noticeable lag

5. Installed Flash 11.4
6. Reloaded http://www.chia-anime.com/alpha/K
> Scrolling is smooth, no noticeable lag

7. Updated to Firefox 17.0b1
8. Reloaded http://www.chia-anime.com/alpha/K
> Scrolling is smooth, no noticeable lag

Both Marcia and I have been unsuccessful in reproducing this issue. Unfortunately, I don't see what more QA can do without more information. Dropping QAWANTED from this bug.

Comment 41

[Alex Keybl [:akeybl]]

We only have one report, and QA/engineering have not been able to reproduce. Untracking for release.

Comment 42

[Danial Horton]

Anthony, your steps don't mention anything about installing StatusbarEX.
Nor do they mention zooming in.

This issue is only reproducible when all the criteria are met

I can reproduce it on multiple systems here, fresh installs of Windows, 17+ on any of the systems and reproduce it when ALL the stated criteria is met.

This is not something only i am seeing either, there are posts about it on the mozillazine forums as well.

Comment 43

[Danial Horton]

And of course you only have one report, all the others who were going to added themselves to the CC list

Comment 44

[u279076]

Apologies for missing those steps Danial. I've now re-run my test in comment 40 with StatusbarEx installed and with various zoom levels. Under no conditions am I able to reproduce any noticeable lag.

Comment 45

[Danial Horton]

Sorry Anthony, Marcia, I did miss a criteria.

The addonbar must be enabled and the statusbarex item showing

I assumed it would make sense for a statusbar addon to require the addonbar to be showing and i did say "(or another extension with a  continually changing gui item)" which should infer that the UI would have to be enabled (Meaning Addonbar)

I do not get the sluggishness either if i start the browser with the addon bar hidden with the the extension enabled.

Comment 46

[u279076]

My test *did* have the add-on bar displaying the StatusbarEX information.

Comment 47

[Danial Horton]

It also clears up if i turn off the addon bar and refresh the page.

I assume a repainting issue under certain configuration then, I'll look into it more. Of course, i still cannot reproduce it under 16 and versions of 17 prior to the changeset i found

The problem stayed after a graphics card replacement so i can rule that out. As can i rule out driver settings.

Can rule out the ICC Profile as well.

Operating System	Microsoft Windows 7 Ultimate
OS Service Pack	Service Pack 1
Internet Explorer	9.0.8112.16421 (IE 9.0)
DirectX	DirectX 11.0
	
Motherboard	
CPU Type	QuadCore Intel Core i7-920, 3800 MHz (19 x 200)
Motherboard Name	Asus Rampage II Gene  
Motherboard Chipset	Intel Tylersburg X58, Intel Nehalem
System Memory	12279 MB  (DDR3-1333 DDR3 SDRAM)
DIMM1: Corsair CML16GX3M4X1600C8	4 GB
DIMM3: Corsair CML16GX3M4X1600C8	4 GB
DIMM5: Corsair CML16GX3M4X1600C8	4 GB
	
Display	
Video Adapter	NVIDIA GeForce GTX 550 Ti  (1048256 KB)
Video Adapter	NVIDIA GeForce GTX 550 Ti  (1048256 KB)
3D Accelerator	nVIDIA GeForce GTX 550 Ti
Monitor	BenQ G2400W (Digital)  [24" LCD]  (LB804967SL0)
Monitor	HP Pavilion VF51  [15" LCD]  (TWTEY05998)

Resolution	1920 x 1200
Color Depth	32-bit
Color Planes	1
Font Resolution	120 dpi
Pixel Width / Height	36 / 36
Pixel Diagonal	51
Vertical Refresh Rate	59 Hz

I suppose 120dpi might influence things somehow?

Comment 48

[u279076]

Bumping up my dpi from 96 to 120 makes no difference on my end. At this point, I think it would be useful for Engineering to try to come up with a solution based on the information Danial has given us. I don't think it's worth putting anymore QA resources into trying to reproduce this internally.

Comment 49

[Danial Horton]

Is there any way to log canvas and paint statistics?

Comment 50

[Danial Horton]

Problem vanishes if i set the Ex display to text only.

something to do with the calculation of the fill bar on setups with lots of memory perhaps?

don't know how this would affect scrolling though?

Comment 51

[foxenesys]

There is definitely something going through those versions :
I was running nightly 18, then I rolled back to Aurora 17.
Recently updated to Aurora 18, I'm rolling back again to Beta 17.

Trying the same pages on both Chrome and IE9 gives a much slicker experience.

Disabling the smooth scrolling features can help a little to alleviate the issue.
I couldn't relate this to the hardware acceleration.

Also this is noticeable on CPU usage (small spikes).

Comment 52

[Danial Horton]

i also noticed 18 and 19 to be less smoother overall than 17, but think its outside the scope of this thread.

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to foxenesys from comment #51)
> There is definitely something going through those versions :
> I was running nightly 18, then I rolled back to Aurora 17.
> Recently updated to Aurora 18, I'm rolling back again to Beta 17.

Which pages is it worst on?

Comment 54

[foxenesys]

Actually I changed my mind.

It seems like this is a general performance issue : while I was typing this, I noticed that there is a small delay between the keystroke and the display.
This is true for Aurora 18 and Nightly 19. 

The scrolling issue can occur on some pages and dissapear the minute after.
BTW, the example on comment 36 is a good one (Although one need to be really peaky to get it).
I can only assume that it isn't related to the rendering nor displaying cores.

So is it because Aurora and Nightly are not targeted for production ?

Generally speaking, it's about response time on user inputs.

Comment 55

[Danial Horton]

the problem demonstrated in comment 36 is mainly how the page seems to be choppy under my apparent configuration (24" 16:10 display with 120dpi) OR something to do with the extensions fill bar with my 12GB of ram slowing down repainting as the bar updates.

It may help to have an extension expert check into that aspect of the extension to see if it can be optimised that side or if it really is a problem on firefox's end on some configurations.

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to foxenesys from comment #54)
> It seems like this is a general performance issue : while I was typing this,
> I noticed that there is a small delay between the keystroke and the display.
> This is true for Aurora 18 and Nightly 19. 
> 
> The scrolling issue can occur on some pages and dissapear the minute after.
> BTW, the example on comment 36 is a good one (Although one need to be really
> peaky to get it).
> I can only assume that it isn't related to the rendering nor displaying
> cores.

It's almost certainly a regression and we need to fix it. Please file a separate bug for it, and CC me. It sounds like something specific in your setup, or the pages you visit, triggers the bug; please add whatever you can figure out to the new bug. Thanks!!!

Comment 57

[foxenesys]

I'm still trying to investigate what is going wrong.
So I'll file another bug report once I clearly settled what is going wrong.

BTW, I noticed one thing that maybe we have in common : When my slowdowns occurs, simply minimizing the window and bringing it up again make the whole interface acting like before.

So, anyone in the same bag ?

Comment 58

[Danial Horton]

I rolled back to 16.0.2

Not for this bug, (which is still present)

but for the scrollbar bug that was introduced in the same time range.

Comment 59

[Danial Horton]

btw, for anyone still looking into this

i found nglayout.debug.paint_flashing in another bug, and tested it with "Text only" on and off

with "Text only" off, the window repaints every time you scroll up and down marked by a lot of flashing, where as there is no such flashing with Text only in use.

I opened a copy of my typical profile in 17 and found that it too flickers, though i had text only enabled in that profile.

It was then i discovered that MemChaser also causes unnecessary repaints as long as it exists on the statusbar.

Comment 60

[Danial Horton]

For comparisons sake, i also just opened that profile copy in 16.0.2, with nglayout.debug.paint_flashing still set to true

There is NO flickering when scrolling, even with MemChaser on the statusbar and "Text only" disabled

Comment 61

[Robert O'Callahan (:roc) (email my personal email if necessary)]

How about FF18, do you still get the excessive repainting there?

Comment 62

[Danial Horton]

in the new profile, with hwa off and memchaser, yes.

I can also trigger the repainting by minimizing and then maximising the screen again.

I know this is a tricky issue to fix guys, especially when the behavior seems to be even inconsistent between a fresh profile and a typically used one - oddly enough i can fix the repaint flashing by just disabling memchaser on my used and abused profile, toggling text only on and off in statusbarex doesn't affect it at all.

I'm assuming that a certain combination of statusbar items can negate or make the issue. Mammon knows how, but thats the only thing i can come up with since hiding the addonbar 100% prevents the issue in both profiles. In my used&abused profile, i can have statusbar ex's fillbar's enabled with no problem, but having memchaser enabled, repainting occurs heavily.

then i go into the fresh profile with only statusbarex and having the fillbars enabled causes the flashing.

Well, regardless of the issue, it all seem's centered around having stuff on the addon bar.  Even the issue where it starts repainting excessively when i minimize and maximize does not occur with the addon bar hidden.

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

thanks. This should be fixable if Matt can reproduce.

Comment 64

[Matt Woodrow (:mattwoodrow)]

Awesome, thanks for the STR.

I can reproduce this on 18, but not on the latest nightly. I suspect that this was fixed by bug 810302.

Can you please confirm that it's fixed for you too.

Probably worth uplifting those fixes to the branches if so.

Comment 65

[Danial Horton]

on Nightly 20 http://hg.mozilla.org/mozilla-central/rev/1942b4d64dc8

enabled memchaser, no repaint flash
resized then maximised the window, reflashes occur.

disabled memchaser, 
enabled statusbarex, restarted browser no repaint flash
set options back to default (text only disabled) flashing returns.

As i said, this is going to be painful to get narrowed down, the behavior seems to change with the users computer, resolution, and possibly memory amount - though i've no actual confirmation that the memory total is involved at all.

Comment 66

[Danial Horton]

tested again with 18-20a / Windows 7

Window dragged to the side to lock and resize to the left or right part of the screen.

extension used
statusbarex
page used http://www.chia-anime.com/alpha/K
*No Zoom*
Maximise - Minimize
Result - No repaint flashes

WITHOUT REFRESHING
Ctrl-+ once
Result - Repaint flashing and chopping scrolling

Refreshing will make scrolling smooth and stop the flashing, 

Maximising while zoomed, zooming in while maximised or zooming after having maximised and returning to a window triggers the excessive repaints with statusbar ex.

And then theres the combination of Statusbarex + Memchaser D:

extensions used
memchaser + statusbarex
page used http://www.chia-anime.com/alpha/K
*No Zoom*
Maximise - Minimize
Result - No repaint flashes

So far, this is the exact same as just having statusbar ex by itself, and this continues throughout the maximised + zoom tests.

However, unlike with just statusbarex.

Restart nightly
memchaser + statusbarex
page used http://www.chia-anime.com/alpha/K
Zoom in once!
Result - Repaint flashing without having maximised at all.

Comment 67

[Danial Horton]

Tested

16 - unaffected
17 - affected
18 - affected
19 - affected
20 - affected
21 - PARTIALLY FIXED 

with Nightly 21 i can  zoom in and out all the way with both Statusbar and Memchaser on the addonbar without the excessive repaint.

However, once i resize the window or maximise it, the excessive repainting returns till i reload the page or create a new tab (creating a new tab helps while switching to one does not)

Comment 68

[Danial Horton]

Oddly my previous results with nightly 21 were inconsistent to the point it made it look like it was partially fixed.

Instead, once memchaser finally counted the iGC latency the flashing resumed.

Comment 69

[Wayne Mery (:wsmwk)]

still seen?

Comment 70

[Danial Horton]

Yes, I've given up on getting a fix and will simply stick with Firefox 16, 

any potential fixes will be tainted by the Australis stuff-up of an interface.

Comment 71

[Wayne Mery (:wsmwk)]

Danial, I also see a bug UI performance hit, but only in the past month or two. And afaict does not involve nglayout.debug.paint_flashing setting. 
Note: for me the performance hit is greatly reduced (by about 15% CPU, down from 30%) if the memchaser UI bit in the toolbar is not visible in the firefox window.

Can you get and upload a gecko (performance) profile using https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/geckoprofiler.xpi ?  First you get the profile (collect), then sharing the profile will give you a URL.
If profiler doesn't work on your version 16 then you may need to test with a more recent version from http://www.mozilla.org/en-US/firefox/channel/

note: memchaser development has stopped

Comment 72

[Wayne Mery (:wsmwk)]

There is also an older version of profiler from 2012 at https://addons.mozilla.org/en-us/firefox/addon/gecko-profiler/ .... I'm not sure how it compares in terms of functionality to the newer one on github

Comment 73

[Danial Horton]

You misunderstand.

The performance issue isn't caused by nglayout.debug.paint_flashing

This setting is used to determine if a performance issue is caused by unnecessary screen repainting.

Comment 74

[Wayne Mery (:wsmwk)]

Fair enough.
Is there a perf hit if the memchaser bits of the status bar are not visible?
(sorry if you've already stated this)

Comment 75

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Also is that still a problem with Australis builds? MemChaser will be put into the navigation bar by the migration code. So I wonder if something could have been changed.

Comment 76

[Danial Horton]

Yes it is still a problem, Already checked it in an Australis build

The issue was explicitly caused by re-factoring layers iirc.

not that i will ever use one.

Comment 77

[Danial Horton]

Yes it is still a problem, Already checked it in an Australis build

not that i will ever use one.

The issue was explicitly caused by re-factoring layers iirc.

Comment 78

[Michelle Funches - QA]

Need to determine if this bug can now be closed:  This is working for me smoothly with out glitches etc...
Version 	45.0
Build ID 	20160303134406
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Version 	46.0a2
Build ID 	20160205004003
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0

Comment 79

[Michelle Funches - QA]

There has not been any recent update and this is working for me. 
Closing this as Resolved -WFM
Feel free to reopen if the problem is seen on a current build.