Closed Bug 1180317 Opened 9 years ago Closed 9 years ago

some image black displayed with Firefox 40.0*

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
40 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox39 --- unaffected
firefox40 + wontfix
firefox41 + fixed
firefox42 + fixed
firefox43 --- fixed
firefox-esr38 --- unaffected

People

(Reporter: patclash, Assigned: seth)

References

Details

(Keywords: qawanted, regression, Whiteboard: [gfx-noted][betabreakers-41])

Attachments

(2 files)

screenshot of the issu
129.05 KB, image/png
Details
Memory dump sent by TWP Marketing
775.25 KB, text/plain
Details
Attached image screenshot of the issu —
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150702173756 Steps to reproduce: I update Firefox 39.0 beta to 40.0b1 on an old machine with AMD Sempron 3000+ processor , ATI RADEON 9250 Browse on some site; for example : http://www.dna.fr/ Actual results: Some image display black note: I also see this issue when I try Dev Ed 40.0a2 and on some newsletter message with Earlybird 40.0a2 Expected results: image should display normally (the same site work perfectly with Firefox 39.0)
I just update aurora 40.0a2 to 41.0a2 and I have the same issue Is it a hardware issue or a regression ? I know the processor doesn't running more then SSE
Could you type about:support and paste here the section "graphics", please.
Component: General → Graphics
Flags: needinfo?(patclash)
Product: Firefox → Core
Here it is : Accélération graphique Date du pilote 5-3-2006 Description de la carte RADEON 9250 Direct2D activé Bloqué pour la version de votre pilote graphique. Essayez de faire la mise à jour de votre pilote graphique vers la version 9.6 ou supérieure. DirectWrite activé false (0.0.0.0) Fenêtres avec accélération graphique 0/1 Basic (OMTC) Bloqué pour la version de votre pilote graphique. Essayez de faire la mise à jour de votre pilote graphique vers la version 9.6 ou supérieure. GPU 2 actif false ID du périphérique 0x5960 ID du sous-système 03321043 ID du vendeur 0x1002 Pilotes de la carte ati2dvag Prise en charge matérielle pour le décodage H264 false RAM de la carte Unknown Rendu WebGL Bloqué pour la version de votre pilote graphique. Essayez de faire la mise à jour de votre pilote graphique vers la version 9.6 ou supérieure. Version du pilote 8.252.0.0 windowLayerManagerRemote true Zoom/Panoramique asynchrones aucun AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0
Flags: needinfo?(patclash)
http://support.amd.com/fr-fr/download/archive/radeon-prer300-xp This is the last driver but I guess it will not change anything.
status-firefox39: --- → unaffected
tracking-firefox40: --- → ?
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
Keywords: regression
As it seems to be a regression about displaying images with old GPU, Milan, could you retriage to the right person when you have some time, please.
Flags: needinfo?(milan)
(In reply to Loic from comment #4) > http://support.amd.com/fr-fr/download/archive/radeon-prer300-xp > This is the last driver but I guess it will not change anything. This is the driver that I have re-intalled last year (the installer is from Nov. 15, 2006 , but the graphic card driver inside is from March 2006 ....
Seth, I ask Bas if this might be gfx related. He noted that there no HWA being used which might indicate that it's not a gfx/layers problem. Could it be related to imagelib/decoder?
Flags: needinfo?(seth)
Whiteboard: [gfx-noted]
It'd be useful to have a regression range for this, see if it happened recently, or if it's something that's been around for a while.
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #8) > It'd be useful to have a regression range for this, see if it happened > recently, or if it's something that's been around for a while. As I say in my first report, I see this the first time when I update Aurora 39.0a2 to Dev Edition 40.0a2 (and the same with update Earlybird 39.0a2 to 40.0a2), around the 15th May 2015. I do not report at this moment because I was thinking it's a preview version that was not stabilized and this issue is only on one machine.
That's great, thanks - any chance of (this will take some time, so I appreciate I'm asking for a lot) of using mozregression tool (http://harthur.github.io/mozregression/) to narrow it down?
Tracking because suspected regression, for 40, 41, 42.
tracking-firefox40: ? → +
tracking-firefox41: ? → +
tracking-firefox42: ? → +
Keywords: regressionwindow-wanted
patclash, could you use the tool mozregression to find a regression range, please.
Flags: needinfo?(patclash)
I have never use this tools and never install a Nightly; I will try, but because I can only reproduce this issue on one of my 3 computers at home, you must wait for the next w-e (and I don't have a good network bandwidth at home) Do I begin on the Nightly merge day between 39.0a1 and 40.0a1 ? (31th March)
Flags: needinfo?(patclash)
If you're not familiar with Mozreg, you can do that manually by downloading Nightly builds from the FTP: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/ You need to use the folder "mozilla-central" to download the daily Nightly like http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/07/2015-07-06-03-02-06-mozilla-central/ for the Nightly of 2015/07/06. Just download the Win32 build as zip, it's a standalone version (no need to install) to unzip on your desktop. After that, you click in firefox.exe in the folder /firefox and it starts the build. You can use a custom profile with a shortcut like C:\Users\<user>d\Desktop\firefox\firefox.exe -P "test" -no-remote. Do that by dichotomy to find fastly the regression range. Nightly 40 started at the end of March, so start to download the 1st build near 2015/03/15.
@patclash I have a detailed walkthrough of using mozregression if it helps: https://wiki.mozilla.org/QA/Platform/Graphics/Guides#Finding_a_Regression_Window I can also help walk you through finding the regression window if you get stuck on that. Feel free to email me at ahughes@mozilla.com if you get stuck.
I've created an account just to add my confirmation of this bug. It is only displayed on JPEG images which have been resized. Native sized JPEG images are correctly displayed. The resized image does display for an instant, on loading, but is immediately replaced with a black box. I've seen this JPEG display problem since FF-dev 40.0a2, approximate dates for the appearance of this problem is the last week of June, 2015. I am currently running FF-dev 41.0a2 with the same JPEG display problem. It is totally reproducible on my laptop system (Hewlett Packard - Pavilion ze4400 (DK583A), CPU: mobile AMD Athlon(tm) XP2200+, 462.6Mb Ram). OS is Kubuntu 14.04.2, current as of this date. This does not occur with FF 38.0, on the same machine. I don't have the ability to run the regression checks on this machine.
TWP, you can do it manually if you want.
I just do some test manually as you ask in comment#14 : the last good build (work without issue on the same site) : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/04/2015-04-01-03-02-04-mozilla-central/ 20150331030204 https://hg.mozilla.org/mozilla-central/rev/8af276ab8636 The first bad build (display bug on the same site) : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/04/2015-04-01-08-51-08-mozilla-central/ 20150401085108 https://hg.mozilla.org/mozilla-central/rev/da2f28836843 It take not so long because I found immediately the last good
Lee, can you reproduce this? We have a day regression range, I wanted to see if we can get a inbound one.
Flags: needinfo?(lsalzman)
(In reply to Loic from comment #17) > TWP, you can do it manually if you want. Nope, my bandwidth is limited to less than 15Kb/s, so downloading Firefox at 53Mb takes an hour each. The best I can do is the approximate week in which the failure appeared on this machine: (last week in June, 2015). I note this does not agree with the reports from patclash, above, so I would go with his information over mine.
(In reply to Milan Sreckovic [:milan] from comment #20) > Lee, can you reproduce this? We have a day regression range, I wanted to > see if we can get a inbound one. At least in my own recent builds, I've not noticed anything like this going on, nor does going to the reported site trigger it. I am guessing that is merely indicative that of the causal factors not being in place, not that this has been actually fixed. It is curious that both reporters have really old Radeon GPUs, but since the drivers are wildly different - I am guessing open radeon/Mesa drivers on the one hand, and legacy Windows drivers on the other - since there should be no AMD support for either of the reporters' GPUs - so maybe that's a red herring and it's more related to RAM constraints? I would wonder if this occurs on an old Intel IGP machine with 512MB RAM, and/or also old Radeon setups. Milan, do we have any lab hardware like that to test this on? That would probably be worthwhile just to rule that out if memory or GPU factors are contributing.
Flags: needinfo?(lsalzman) → needinfo?(milan)
Nothing jumps out at me in the regression range. I don't see any image-related changes in there at all. (In reply to TWP Marketing from comment #16) > It is only displayed on JPEG images which have been resized. Native sized > JPEG images are correctly displayed. > > The resized image does display for an instant, on loading, but is > immediately replaced with a black box. This points to either HQ scaling or downscale-during-decode, but that makes the regression range even odder, as I see nothing related to those things in the regression range. People who can reproduce this, can try these experiments and see if any of them fix it? - Set "image.high_quality_downscaling.enabled" to false in about:config. - Set "image.downscale-during-decode.enabled" to false in about:config. - See if Nightly has fixed the problem. I'm really just guessing here, but without a more accurate regression range I'm kinda at a loss.
Flags: needinfo?(seth)
Maybe also worth trying: - Set "image.mem.allow_locking_in_content_processes" to false.
Another worth trying: - Set "layers.offmainthreadcomposition.enabled" to false. It's worth trying all of these; please don't stop just because one fixes the problem.
Also, does resizing the window fix the problem?
Ok, Success, the images now display correctly on my system. 1) resizing the window does NOT fix. 2) Individually, the suggested changes in about:config do NOT work 3) Combined, all four changes DO work. Resized JPEG images are displayed correctly The four changes to about:config are: - Set "layers.offmainthreadcomposition.enabled" to false. - Set "image.high_quality_downscaling.enabled" to false in about:config. - Set "image.downscale-during-decode.enabled" to false in about:config. - Set "image.mem.allow_locking_in_content_processes" to false. I have not yet done the iterative process of trying combinations of these four settings
(In reply to TWP Marketing from comment #27) > 1) resizing the window does NOT fix. > 2) Individually, the suggested changes in about:config do NOT work > 3) Combined, all four changes DO work. Resized JPEG images are displayed > correctly This is *very* interesting. If you can figure out which of the pref changes are important, that will be a big step forward in figuring out what's happening here.
More testing results based on the suggested parameters in about:config This combination works: - Set "image.downscale-during-decode.enabled" to false - Set "image.high_quality_downscaling.enabled" to false - Set "image.mem.allow_locking_in_content_processes" to false. - Set "layers.offmainthreadcomposition.enabled" to false Trying various combinations of the four parameters, I found that two effect the display of scaled JPEG images. They work if both are set to false. - Set "image.downscale-during-decode.enabled" to false - Set "layers.offmainthreadcomposition.enabled" to false The other two parameters do not appear to effect this problem. The second parameter ("layers.offmainthreadcomposition.enabled") has a variable effect, when set to true, SOME (not all) scaled JPEG images are displayed correctly and other are not. All scaled JPEG images display correctly when BOTH of these parameters are set to false. I used this URL to test: http://www.breitbart.com/ There are several scaled JPEG images as you scroll down the home page. The first is near the center of the first screen, labeled "Vote Now". The next are about three screens down, consisting of three images in a row under the heading "Breitbart TV".
(In reply to TWP Marketing from comment #29) > Trying various combinations of the four parameters, I found that two effect > the display of scaled JPEG images. They work if both are set to false. > > - Set "image.downscale-during-decode.enabled" to false > - Set "layers.offmainthreadcomposition.enabled" to false > > The other two parameters do not appear to effect this problem. > > The second parameter ("layers.offmainthreadcomposition.enabled") has a > variable effect, when set to true, SOME (not all) scaled JPEG images are > displayed correctly and other are not. > > All scaled JPEG images display correctly when BOTH of these parameters are > set to false. > I just test that two parameter on my Firefox 40.0b2 : - Set "image.downscale-during-decode.enabled" to false - Set "layers.offmainthreadcomposition.enabled" to false (I don't change other parameter) all seems good now, images display normaly :) PS : That the trick ; I just do the same setting on Earlybird 40.0a2 and all the images show normaly now
And now, when I restart my machine this morning, the configuration settings in about:config do not "stick". I had to reset the two parameters to get scaled JPEG images to display correctly. It is off-topic, but any suggestion on how to make the change permanent would help.
Lee, what do you make of this? It's bizarre to me that it's necessary to set *both* "image.downscale-during-decode.enabled" to false and "layers.offmainthreadcomposition.enabled" to false to fix this problem. Something quite odd is going on here.
Flags: needinfo?(lsalzman)
Flags: needinfo?(lsalzman)
(In reply to patclash from comment #30) > (In reply to TWP Marketing from comment #29) > > > Trying various combinations of the four parameters, I found that two effect > > the display of scaled JPEG images. They work if both are set to false. > > > > - Set "image.downscale-during-decode.enabled" to false > > - Set "layers.offmainthreadcomposition.enabled" to false > > > > The other two parameters do not appear to effect this problem. > > > > The second parameter ("layers.offmainthreadcomposition.enabled") has a > > variable effect, when set to true, SOME (not all) scaled JPEG images are > > displayed correctly and other are not. > > > > All scaled JPEG images display correctly when BOTH of these parameters are > > set to false. > > > > > I just test that two parameter on my Firefox 40.0b2 : > - Set "image.downscale-during-decode.enabled" to false > - Set "layers.offmainthreadcomposition.enabled" to false > (I don't change other parameter) > > all seems good now, images display normaly :) > > PS : That the trick ; > I just do the same setting on Earlybird 40.0a2 and all the images show > normaly now Can you see if setting just one of those to false, but not the other (make sure to reset them to true first), fixes it for you? You're on a different platform than TWP Marketing, so I'd just like confirmation that the symptoms are not actually different.
Flags: needinfo?(patclash)
(In reply to Lee Salzman [:eihrul] from comment #33) > (In reply to patclash from comment #30) > > I just test that two parameter on my Firefox 40.0b2 : > > - Set "image.downscale-during-decode.enabled" to false > > - Set "layers.offmainthreadcomposition.enabled" to false > > (I don't change other parameter) > > > > all seems good now, images display normaly :) > > > > PS : That the trick ; > > I just do the same setting on Earlybird 40.0a2 and all the images show > > normaly now > > Can you see if setting just one of those to false, but not the other (make > sure to reset them to true first), fixes it for you? You're on a different > platform than TWP Marketing, so I'd just like confirmation that the symptoms > are not actually different. I just do some test after reset the parameters : So I confirm that on my platform (Windows XP SP3)with Aurora 41.0a2 I need to set the two parameter to false (if only "image.downscale-during-decode.enabled" set to false alone or"layers.offmainthreadcomposition.enabled" set to false alone that do nothing (the bug stay) I have close and restart Aurora after each change
Flags: needinfo?(patclash)
Flags: needinfo?(pay_me.gold)
Keywords: qawanted
I'd also be interested to see an about:memory dump taken while the problem is happening. (You'd want to open about:memory in a different window, not a different tab, so that you don't disturb the state of the window that's reproducing the problem.)
I reset the parameter: image.downscale-during-decode.enabled to true Check the URL (above) used for testing to confirm that the problem IS present. Opened a new window and have the first memory dump using about:memory. I can do other dumps if you wish. This is on the linux system The dump is over 580Kb and I can't embed it here. Short of sending about ten comments here, I don't see an easy way to show you the dump. Suggestion: email it to you?
Flags: needinfo?(pay_me.gold)
Seth I've sent you an email containing the attachment file of the memory dump it is large...
This may not be significant, but I notice, on my slow system, that if I load the test url: breitbart.com, change to another tab during download and let it completely download, the scaled JPEG images will appear for about half a second when I switch back to the breitbart tab. They are almost immediately replaced with black boxes, but the converted image is available, so the image conversion did occur.
And another piece of evidence. Upon resetting image.downscale-during-decode.enabled back to false, without rebooting, but forcing a page reload of brietbart.com, one of the three images under "Breitbart TV" does display, the other two are still black boxes.
Enough information to make this depend on the downscale-during-decode bug 1124084... TWP Marketing - what happens for you with the two builds from comment 35?
Assignee: nobody → seth
Blocks: 1124084
Flags: needinfo?(milan)
(In reply to TWP Marketing from comment #38) > Seth > I've sent you an email containing the attachment file of the memory dump > it is large... It's fine to upload large files as attachments to the bug. It looks like you copied and pasted the contents of about:memory. I'm sorry, I should've explained better: in the future, to capture a memory report, click on "Measure and save" in about:memory, then upload the resulting file to the bug. I think we can work with what you've sent though, so no need to go through the process again. It looks to me like you are hitting an allocation failure. There are some very large images on that page, and it looks to me like we're creating surfaces for them that don't have any associated textures. There must be some code path that isn't handling failures correctly.
(In reply to Milan Sreckovic [:milan] from comment #41) > Enough information to make this depend on the downscale-during-decode bug > 1124084... I'm honestly not convinced. I think this is a low-memory issue. Keep in mind that it still happens if layers.offmainthreadcomposition.enabled set to true, even if image.downscale-during-decode.enabled is set to false.
No longer blocks: 1124084
(In reply to Milan Sreckovic [:milan] from comment #41) > Enough information to make this depend on the downscale-during-decode bug > 1124084... > > TWP Marketing - what happens for you with the two builds from comment 35? Each download (53+Mb) takes about an hour on my system (15Kb/s connection). I would rather not attempt except on a weekend when my wireless is less used and I have time to wait.
Here's an example of the suspicious output from about:memory: │ │ ├────188,528 B (00.12%) -- image(1920x2000, http://www.breitbart.com/t/assets/i/breitbart-2016-primary-background.jpg) │ │ │ ├──188,480 B (00.12%) ── source │ │ │ └───────48 B (00.00%) ── locked/surface(1920x2000@0)/decoded-heap Note that here we have a very large image (1920x2000, which would result in a ~15MB texture) with a locked surface that allegedly only takes up 48 bytes of heap? Somewhere an allocation is failing and we're not catching it. It's obvious that we're not catching it, because the surface is still present in the SurfaceCache. If we detected the error, we'd have removed it when we tried to draw it. (And it's pretty clear we'd have tried to draw it, because it's locked.)
Seth, I'm not competent enough to say for sure, but because the image does actually decode and IS drawn to the screen (it flashes for a fraction of a second before blanking), it may be a timing issue on this system (low RAM, slow processor, and slow net connection).
Anything error messages about:support graphics section when "bad things happen"? Although, the only possible ones from imagelib code are the "* failed to map surface" and I don't know if the OOM that Seth suggests would end up there.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #35) > Can you try these two builds: > http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/ > tinderbox-builds/mozilla-inbound-win32/1427728999/ > http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/ > tinderbox-builds/mozilla-inbound-win32/1427729479/ I just try this two builds : these two work for me, no display bug
Flags: needinfo?(patclash)
(In reply to TWP Marketing from comment #47) > Seth, I'm not competent enough to say for sure, but because the image does > actually decode and IS drawn to the screen (it flashes for a fraction of a > second before blanking), it may be a timing issue on this system (low RAM, > slow processor, and slow net connection). Yes, that makes perfect sense. That may either be because the error is happening after the initial decode (for example when we "optimize" the image to better suit the graphics backend you're using) or because we made a second, scaled copy of the image (HQ scaling and downscale-during-decode do this) and it's the second copy that's running into an error.
(In reply to Milan Sreckovic [:milan] from comment #41) > Enough information to make this depend on the downscale-during-decode bug > 1124084... > > TWP Marketing - what happens for you with the two builds from comment 35? Also, the two build links point to a Win32 build. If you can give me links to the linux builds, I will certainly look at testing them this weekend when I have better access.
I have the same issue. This is the section "Graphics" from about:support Adapter Description Mesa Project -- Mesa DRI R200 (RV280 5964) x86/MMX+/3DNow!+/SSE DRI2 Asynchronous Pan/Zoom none Device ID Mesa DRI R200 (RV280 5964) x86/MMX+/3DNow!+/SSE DRI2 Driver Version 1.3 Mesa 10.5.8 GPU Accelerated Windows 0/1 Basic Blocked for your graphics card because of unresolved driver issues. Vendor ID Mesa Project WebGL Renderer Blocked for your graphics card because of unresolved driver issues. windowLayerManagerRemote false AzureCanvasBackend cairo AzureContentBackend cairo AzureFallbackCanvasBackend none AzureSkiaAccelerated 0 My PC: Video card ATI Radeon 9200, AMD Athlon XP, 1500 MHz, 512 RAM. Forum: http://forums.mozillazine.org/viewtopic.php?f=23&t=2945915 http://mozillaes.org/foros/viewtopic.php?f=7&t=49048
(In reply to logiuser from comment #52) > I have the same issue. This is the section "Graphics" from about:support > > > Adapter Description Mesa Project -- Mesa DRI R200 (RV280 5964) > x86/MMX+/3DNow!+/SSE DRI2 > Asynchronous Pan/Zoom none > Device ID Mesa DRI R200 (RV280 5964) x86/MMX+/3DNow!+/SSE DRI2 > Driver Version 1.3 Mesa 10.5.8 > GPU Accelerated Windows 0/1 Basic Blocked for your graphics card because of > unresolved driver issues. > Vendor ID Mesa Project > WebGL Renderer Blocked for your graphics card because of unresolved driver > issues. > windowLayerManagerRemote false > AzureCanvasBackend cairo > AzureContentBackend cairo > AzureFallbackCanvasBackend none > AzureSkiaAccelerated 0 > > My PC: > > Video card ATI Radeon 9200, AMD Athlon XP, 1500 MHz, 512 RAM. > > > Forum: > > http://forums.mozillazine.org/viewtopic.php?f=23&t=2945915 > > http://mozillaes.org/foros/viewtopic.php?f=7&t=49048 Graphics from Firefox 40 beta version: Graphics Adapter Description Mesa Project -- Mesa DRI R200 (RV280 5964) x86/MMX+/3DNow!+/SSE DRI2 Asynchronous Pan/Zoom none Device ID Mesa DRI R200 (RV280 5964) x86/MMX+/3DNow!+/SSE DRI2 Driver Version 1.3 Mesa 10.5.8 GPU Accelerated Windows 0/1 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues. Supports Hardware H264 Decoding false Vendor ID Mesa Project WebGL Renderer Blocked for your graphics card because of unresolved driver issues. windowLayerManagerRemote true AzureCanvasBackend cairo AzureContentBackend cairo AzureFallbackCanvasBackend none AzureSkiaAccelerated 0 Example website: https://www.reddit.com/
(In reply to Seth Fowler [:seth] from comment #23) > Nothing jumps out at me in the regression range. I don't see any > image-related changes in there at all. > > (In reply to TWP Marketing from comment #16) > > It is only displayed on JPEG images which have been resized. Native sized > > JPEG images are correctly displayed. > > > > The resized image does display for an instant, on loading, but is > > immediately replaced with a black box. > > This points to either HQ scaling or downscale-during-decode, but that makes > the regression range even odder, as I see nothing related to those things in > the regression range. > > People who can reproduce this, can try these experiments and see if any of > them fix it? > > - Set "image.high_quality_downscaling.enabled" to false in about:config. > - Set "image.downscale-during-decode.enabled" to false in about:config. > - See if Nightly has fixed the problem. > > I'm really just guessing here, but without a more accurate regression range > I'm kinda at a loss. SOLVED: Hi. Setting "image.downscale-during-decode.enabled" to "false" fixed my Firefox 40 beta trouble. Now the browser works fine. Thank you very much. image.downscale-during-decode.enabled true http://subefotos.com/ver/?a7d868e9a65c6d3bbb23ee92083f8238o.png image.downscale-during-decode.enabled false (fixed) http://subefotos.com/ver/?50bd457ca34e5b40bcab379948b69d8co.png
(In reply to patclash from comment #34) > (In reply to Lee Salzman [:eihrul] from comment #33) > > (In reply to patclash from comment #30) > > > I just test that two parameter on my Firefox 40.0b2 : > > > - Set "image.downscale-during-decode.enabled" to false > > > - Set "layers.offmainthreadcomposition.enabled" to false > > > (I don't change other parameter) > > > > > > all seems good now, images display normaly :) > > > > > > PS : That the trick ; > > > I just do the same setting on Earlybird 40.0a2 and all the images show > > > normaly now > > > > Can you see if setting just one of those to false, but not the other (make > > sure to reset them to true first), fixes it for you? You're on a different > > platform than TWP Marketing, so I'd just like confirmation that the symptoms > > are not actually different. > > I just do some test after reset the parameters : > So I confirm that on my platform (Windows XP SP3)with Aurora 41.0a2 I need > to set the two parameter to false > (if only "image.downscale-during-decode.enabled" set to false alone > or"layers.offmainthreadcomposition.enabled" set to false alone that do > nothing (the bug stay) > > I have close and restart Aurora after each change I just redo a test with resetting "layers.offmainthreadcomposition.enabled" to default (true) and restart Aurora 41.0a2 after reading comment#54 and all work well witout the image issue
(In reply to kfung from comment #55) > TWP Marketing, I think these are the links to the linux builds: > http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/ > tinderbox-builds/mozilla-inbound-linux/1427728999/ > http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/ > tinderbox-builds/mozilla-inbound-linux/1427729479/ Thanks, I'll pull these on Saturday, test and report.
(In reply to patclash from comment #56) > I just redo a test with resetting "layers.offmainthreadcomposition.enabled" > to default (true) > and restart Aurora 41.0a2 after reading comment#54 and all work well witout > the image issue Just to double check - you're saying that if you set "image.downscale-during-decode.enabled" to false, but leave "layers.offmainthreadcomposition.enabled" set to true, then you no longer see the issue?
Flags: needinfo?(patclash)
(In reply to Seth Fowler [:seth] from comment #58) > (In reply to patclash from comment #56) > > I just redo a test with resetting "layers.offmainthreadcomposition.enabled" > > to default (true) > > and restart Aurora 41.0a2 after reading comment#54 and all work well witout > > the image issue > > Just to double check - you're saying that if you set > "image.downscale-during-decode.enabled" to false, but leave > "layers.offmainthreadcomposition.enabled" set to true, then you no longer > see the issue? Yes, and I've test this too with Firefox 40.0b2 :)
Flags: needinfo?(patclash)
OK, sounds like this should block DDD then. Hopefully there aren't multiple problems happening here for different people =\
Blocks: 1124084
For anyone who can reproduce this: I've created a custom build with some new prefs that will help narrow down the problem. I'd appreciate it if you could try it out. The Windows version is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-968dfbd9a64b/try-win32/ The Linux version is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-968dfbd9a64b/try-linux64/ I added two new prefs in this build, "image.decode-progressively.enabled" and "image.layers.enabled". It'd be great if you could test them as follows: (1) Set both "image.downscale-during-decode.enabled" and "layers.offmainthreadcomposition.enabled" to true, and verify that you can still reproduce the problem on this build. (2) Experiment with setting "image.decode-progressively.enabled" and/or "image.layers.enabled" to false. You don't need to restart the browser when you change these prefs, but you do need to shift-reload the tab you're using for testing. See if either of these new prefs has an effect on the black image problem. (3) Set all of the prefs above to true, and verify that setting "image.downscale-during-decode.enabled" to false still fixes the problem on this build. Thanks for your help with tracking down the problem!
Result of tests on two nightly Linux build. Using test URL http://breitbard.com as a test site containing scaled JPEG images Images used for testing are located about two/three screens below top, under the heading Breitbart TV, three images in a row. Also using test URL https://www.kubuntuforums.net/forum.php as a test site containing scaled JPEG images Images used for testing are icons in the right hand column TESTING RESULTS: -------------------- firefox-39.0a1.en-US.linux-i686.tar.bz2 dated 3/30/15 15:30 URL: http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox- builds/mozilla-inbound-linux/1427728999/ Initial settings from about:config: layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true Fails: Scaled JPEG image download fails (badly torn black/blue display in image boxes) NOTE: the images are correctly displayed for a fraction of a second before being replaced with the black/blue torn image in box. Test settings from about:config: layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;false Success: Scaled JPEG image download is displayed correctly Test settings from about:config: layers.offmainthreadcomposition.enabled;false image.downscale-during-decode.enabled;true Fails: Scaled JPEG image download fails (scaled JPEG images are displayed as badly torn black/blue boxes) Test settings from about:config: layers.offmainthreadcomposition.enabled;false image.downscale-during-decode.enabled;false Success: Scaled JPEG image download is displayed correctly ------------------ firefox-39.0a1.en-US.linux-i686.tar.bz2 dated 3/30/15 16:03 URL: http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox- builds/mozilla-inbound-linux/1427729479/ Initial settings from about:config: layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true Fails: Test settings from about:config: layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;false Success: Scaled JPEG image download is displayed correctly Test settings from about:config: layers.offmainthreadcomposition.enabled;false image.downscale-during-decode.enabled;true Fails: same as previous version, above. Test settings from about:config: layers.offmainthreadcomposition.enabled;false image.downscale-during-decode.enabled;false Success: Scaled JPEG image download is displayed correctly
(In reply to Seth Fowler [:seth] from comment #62) > For anyone who can reproduce this: I've created a custom build with some new > prefs that will help narrow down the problem. I'd appreciate it if you could > try it out. > > The Windows version is here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-win32/ > > The Linux version is here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-linux64/ > > I added two new prefs in this build, "image.decode-progressively.enabled" > and "image.layers.enabled". It'd be great if you could test them as follows: > > (1) Set both "image.downscale-during-decode.enabled" and > "layers.offmainthreadcomposition.enabled" to true, and verify that you can > still reproduce the problem on this build. > > (2) Experiment with setting "image.decode-progressively.enabled" and/or > "image.layers.enabled" to false. You don't need to restart the browser when > you change these prefs, but you do need to shift-reload the tab you're using > for testing. See if either of these new prefs has an effect on the black > image problem. > > (3) Set all of the prefs above to true, and verify that setting > "image.downscale-during-decode.enabled" to false still fixes the problem on > this build. > > Thanks for your help with tracking down the problem! Seth, I note that your latet test build is for 64 bit. My system is 32bit. Will this even run on my system?
(In reply to Milan Sreckovic [:milan] from comment #65) > There should be a 32-bit build right next to it - > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-linux/ Got it. The first link pointed a only the 64bit build. I download and try this this afternoon.
(In reply to TWP Marketing from comment #66) > Got it. The first link pointed a only the 64bit build. > I download and try this this afternoon. Thanks so much! I'll be very interested to see the results.
Testing of Firefox 42.0a1 custom build filename: firefox-42.0a1.en-US.linux-i686.tar.bz2 source URL: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com- 968dfbd9a64b/try-linux/ First set parameters to true in about:config layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true image.decode-progressively.enabled;true image.layers.enabled;true Test using three URL's https://www.reddit.com/r/firefox/ http://www.breitbart.com/ http://phys.org/ All three URL's confirm the failure of scaled JPEG images, which load and display for a fraction of a second and then revert to either black boxes or black and blue torn images. ============ Next change parameter image.decode-progressively.enable to false layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true image.decode-progressively.enabled;false image.layers.enabled;true All three test URL's confirm failure to display scaled JPEG images ============ Next change parameter image.decode-progressively.enable BACK to true change parameter image.layers.enabled to false layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true image.decode-progressively.enabled;true image.layers.enabled;false Differing results for this configuration: Breitbart.com failed to display scaled JPEG images reddit.com/r/firefox failed to display scaled JPEG images phys.org successfully display scaled JPEG images ============ Next change parameter image.decode-progressively.enable BACK to false change parameter image.layers.enabled to false layers.offmainthreadcomposition.enabled;true image.downscale-during-decode.enabled;true image.decode-progressively.enabled;false image.layers.enabled;false Differing results for this configuration: Breitbart.com failed to display scaled JPEG images reddit.com/r/firefox failed to display scaled JPEG images phys.org successfully display scaled JPEG images =================== In the case of any failure, the images do display for a fraction of a second before being replaced by either a black box or a box containing a black/blue torn image.
(In reply to Seth Fowler [:seth] from comment #62) > For anyone who can reproduce this: I've created a custom build with some new > prefs that will help narrow down the problem. I'd appreciate it if you could > try it out. > > The Windows version is here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-win32/ > > The Linux version is here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-linux64/ > > I added two new prefs in this build, "image.decode-progressively.enabled" > and "image.layers.enabled". It'd be great if you could test them as follows: > > (1) Set both "image.downscale-during-decode.enabled" and > "layers.offmainthreadcomposition.enabled" to true, and verify that you can > still reproduce the problem on this build. > > (2) Experiment with setting "image.decode-progressively.enabled" and/or > "image.layers.enabled" to false. You don't need to restart the browser when > you change these prefs, but you do need to shift-reload the tab you're using > for testing. See if either of these new prefs has an effect on the black > image problem. > > (3) Set all of the prefs above to true, and verify that setting > "image.downscale-during-decode.enabled" to false still fixes the problem on > this build. > > Thanks for your help with tracking down the problem! I can not try your try-win32 build, I got the message : "Couln't load XPCOM"
Just an addendum, I confirm that my video processor is also a Radeon chip: From about:support Mesa Project -- Mesa DRI R100 (RS100 4336) x86/MMX+/3DNow!+/SSE NO-TCL DRI2 I can supply the entire dump of about:support if needed
I'm on beta channel, and once the update done today I started to see these black pictures. I confirm the bug on a linux box, and also on its windows XP virtual box After reading most of this topic, I tried to toggle one pref About:config I have switched image.downscale-during-decode.enabled to false Then, without restart, pîctures were correctly rendered after reloading pages through Ctrl+Alt+R About:support Accélération graphique Description de la carte NVIDIA Corporation -- GeForce FX 5200/AGP/SSE/3DNOW! Fenêtres avec accélération graphique 0/1 Basic (OMTC) Bloqué pour la version de votre pilote graphique. Essayez de faire la mise à jour de votre pilote graphique vers la version NVIDIA 257.21 ou supérieure. ID du périphérique GeForce FX 5200/AGP/SSE/3DNOW! ID du vendeur NVIDIA Corporation Prise en charge matérielle pour le décodage H264 false Rendu WebGL Bloqué pour la version de votre pilote graphique. Essayez de faire la mise à jour de votre pilote graphique vers la version NVIDIA 257.21 ou supérieure. Version du pilote 2.1.2 NVIDIA 173.14.30 windowLayerManagerRemote true Zoom/Panoramique asynchrones aucun AzureCanvasBackend cairo AzureContentBackend cairo AzureFallbackCanvasBackend none AzureSkiaAccelerated 0
(In reply to TWP Marketing from comment #68) > Testing of Firefox 42.0a1 custom build > filename: firefox-42.0a1.en-US.linux-i686.tar.bz2 > source URL: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-968dfbd9a64b/try-linux/ > > First set parameters to true in about:config > > layers.offmainthreadcomposition.enabled;true > image.downscale-during-decode.enabled;true > image.decode-progressively.enabled;true > image.layers.enabled;true > > Test using three URL's > https://www.reddit.com/r/firefox/ > http://www.breitbart.com/ > http://phys.org/ > > All three URL's confirm the failure of scaled JPEG images, which load and > display for a fraction of a second and then revert to either black boxes or > black and blue torn images. > > ============ Let me summarize what TWP Marketing said as follow : true true true true => failed failed failed or even shorter : 1;1;1;1 > 0;0;0 So TWP Marketing tests resulted in : 1;1;1;1 > 0;0;0 1;1;0;1 > 0;0;0 1;1;1;0 > 0;0;1 1;1;0;0 > 0;0;1 I ran the same tests, but do not get the same results : 1;1;1;1 > 0;0;0 1;1;0;1 > 0;0;0 1;1;1;0 > 0;0;0 1;1;0;0 > 0;0;0
(In reply to Seth Fowler [:seth] from comment #62) > For anyone who can reproduce this: I've created a custom build with some new > prefs that will help narrow down the problem. I'd appreciate it if you could > try it out. I used the 32bit Linux version (like TWP Marketing) http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-968dfbd9a64b/try-linux/ (1) I confirm failed display 1;1;1;1 > 0;0;0 (2) 1;1;0;1 > 0;0;0 1;1;1;0 > 0;0;0 1;1;0;0 > 0;0;0 None of these new prefs has an effect on the black image problem. (3) 1;0;1;1 > 1;1;1 I verify that setting "image.downscale-during-decode.enabled" to false still fixes the problem on this build
I see that Tonin is using a Gforce chip with the Nvidia driver. My configuration is a Radeon chip. I believe that Patclash also has a Radeon chip Patclash and I both have low RAM configurations. I'm not sure about Tonin's RAM configuration. I'm not sure this is enough information to modify the Firefox installation process for detecting the problematic end user configurations. But it is a start.
Thanks for trying the builds and giving your feedback, everyone. The results, unfortunately, disprove my original theory about what was causing this problem. ("image.downscale-during-decode.enabled" is clearly triggering the problem, but the question is: why?) I have another idea, so all is not lost. I'm going to consult with Lee to see if he has any ideas and I should have a new build up with some new prefs later today.
OK, I've uploaded a new build with a bunch of new prefs to try. Hopefully this will be enough to give us a clue about the source of the bug. Linux: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-ab9929f250c6/try-linux/ Linux64: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-ab9929f250c6/try-linux64/ Windows: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-ab9929f250c6/try-win32/ The prefs from the previous build (image.decode-progressively.enabled and image.layers.enabled) are still around, but I don't think we need to re-test them. You can leave them on the default value of "true". Definitely make sure that image.downscale-during-decode.enabled is set to "true" as well. It's not a new pref, but I'd recommend setting image.single-color-optimization.enabled to "false" during testing, because I think that optimization could confuse the results. So here are the prefs that you can test in this build (all with a default value of "true", so experiment with setting them to "false" in your testing): image.mem.surfacecache.trust-surfaces.enabled image.optimize.enabled image.downscale-during-decode.unlock image.downscale-during-decode.allow-scaling image.decode.retry-on-alloc-failure Hopefully one of them will fix the problem. I also added a new pref which may make the problem *worse* when you set it to "false". I'd be interested to hear whether it makes any difference: image.downscale-during-decode.only-if-scaling Again, you don't need to restart Firefox when you change these prefs, but you *do* need to shift-reload the page you're testing. Thanks so much to everyone that's been willing to help test these builds! This problem is proving really hard to track down, because nobody at Mozilla has a machine that can reproduce it. But I'm hoping that using these test builds, we can narrow down the problem enough that we can still get it fixed. We couldn't do it without you!
Test using three URL's https://www.reddit.com/r/firefox/ http://www.breitbart.com/ http://phys.org/ 1) Check six preferences in about:config and ensure the are initially set to true. Set seventh preference (image.single-color-optimization.enabled) to FALSE image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true PROBLEM: image.decode.retry-on-alloc-failure This preference is not visible in about:config. Cannot test this preference Set sixth parameter; image.downscale-during-decode.only-if-scaling to true image.downscale-during-decode.only-if-scaling;true Seventh preference set to false image.single-color-optimization.enabled;false NOTE: From the earlier testing in this thread, the following preferences remain set per my previous report [comment 63]: layers.offmainthreadcomposition.enabled;false image.downscale-during-decode.enabled;false 2) With the exception of the missing preference, testing was conducted on each of the three test URL's. Test 1 - image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT VISIBLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed Test 2 image.mem.surfacecache.trust-surfaces.enabled;false image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Fail, scaled JPEG image displayed - However images were flickering on and off, not the just JPEGs, but other icons and header images. Also various icons on the Firefox header flicker on and off. http://www.breitbart.com/ Fail, scaled JPEG image displayed - However images were flickering on and off, not the just JPEGs, but other icons and header images. Also various icons on the Firefox header flicker on and off. http://phys.org/ Fail, scaled JPEG image displayed - However images were flickering on and off, not the just JPEGs, but other icons and header images. Also various icons on the Firefox header flicker on and off. Test 3 image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;false image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed Test 4 image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;false image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed Test 5 image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;false image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed Test 6 image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;false image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed Test 7 image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.decode.retry-on-alloc-failure =============================NOT AVAILABLE image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;true https://www.reddit.com/r/firefox/ Success, scaled JPEG image correctly displayed http://www.breitbart.com/ Success, scaled JPEG image correctly displayed http://phys.org/ Success, scaled JPEG image correctly displayed
About my hardware RAM 2.2 Gio AMD Athlon(tm) XP 2400+ (In reply to Seth Fowler [:seth] from comment #78) > Linux: Tests ran on https://www.google.fr/search?q=firefox (it's loading faster here) > Hopefully one of them will fix the problem. Setting image.downscale-during-decode.allow-scaling to false makes images displayed correctly (it's even not necessary to reload tab) (Toggling other asked prefs have no effect - and yes, one of them is not visible) > I'd be interested to hear whether it makes any difference: Setting image.downscale-during-decode.only-if-scaling to false makes the tab crash, quote : Bad news first: This tab has crashed Now for the good news: You can just close this tab, restore it or restore all your crashed tabs. Submit a crash report to help prevent more bad news
(In reply to TWP Marketing from comment #79) > PROBLEM: > image.decode.retry-on-alloc-failure > This preference is not visible in about:config. Cannot test this > preference You can add a new variable in about:config, just create a new boolean (right click on any variable), and name it 'image.decode.retry-on-alloc-failure'.
(In reply to Loic from comment #81) Toggling image.decode.retry-on-alloc-failure new variable has no effect
(In reply to Seth Fowler [:seth] from comment #78) > OK, I've uploaded a new build with a bunch of new prefs to try. Hopefully > this will be enough to give us a clue about the source of the bug. > > Linux: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-ab9929f250c6/try-linux/ > Linux64: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-ab9929f250c6/try-linux64/ > Windows: > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-ab9929f250c6/try-win32/ > > The prefs from the previous build (image.decode-progressively.enabled and > image.layers.enabled) are still around, but I don't think we need to re-test > them. You can leave them on the default value of "true". Definitely make > sure that image.downscale-during-decode.enabled is set to "true" as well. > It's not a new pref, but I'd recommend setting > image.single-color-optimization.enabled to "false" during testing, because I > think that optimization could confuse the results. > > So here are the prefs that you can test in this build (all with a default > value of "true", so experiment with setting them to "false" in your testing): > > image.mem.surfacecache.trust-surfaces.enabled > image.optimize.enabled > image.downscale-during-decode.unlock > image.downscale-during-decode.allow-scaling > image.decode.retry-on-alloc-failure > > Hopefully one of them will fix the problem. > > I also added a new pref which may make the problem *worse* when you set it > to "false". I'd be interested to hear whether it makes any difference: > > image.downscale-during-decode.only-if-scaling > > Again, you don't need to restart Firefox when you change these prefs, but > you *do* need to shift-reload the page you're testing. > > Thanks so much to everyone that's been willing to help test these builds! > This problem is proving really hard to track down, because nobody at Mozilla > has a machine that can reproduce it. But I'm hoping that using these test > builds, we can narrow down the problem enough that we can still get it > fixed. We couldn't do it without you! I couldn't try the Win32 build on the pc that have the bug, Nightly doesn't start; I got the message again (same as Comment#69) : "Couln't load XPCOM"
(In reply to TWP Marketing from comment #79) > image.decode.retry-on-alloc-failure > This preference is not visible in about:config. Cannot test this > preference Don't worry about it. That one is unlikely to make a difference. > NOTE: From the earlier testing in this thread, the following preferences > remain > set per my previous report [comment 63]: > > layers.offmainthreadcomposition.enabled;false > image.downscale-during-decode.enabled;false Sorry, I should have emphasized this more. I need you to test these other prefs with "layers.offmainthreadcomposition.enabled" set to "true" and "image.downscale-during-decode.enabled" set to "true". Unfortunately, without those prefs set to true, the results don't tell us anything.
(In reply to patclash from comment #83) > I couldn't try the Win32 build on the pc that have the bug, Nightly doesn't > start; > I got the message again (same as Comment#69) : "Couln't load XPCOM" Milan, do you know what's going on with this?
Flags: needinfo?(milan)
(In reply to Seth Fowler [:seth] from comment #84) > Sorry, I should have emphasized this more. I need you to test these other > prefs with "layers.offmainthreadcomposition.enabled" set to "true" and > "image.downscale-during-decode.enabled" set to "true". Unfortunately, > without those prefs set to true, the results don't tell us anything. Please restart the browser after changing these two prefs, by the way. "layers.offmainthreadcomposition.enabled" needs a browser restart to take effect, IIRC.
(In reply to Seth Fowler [:seth] from comment #85) > (In reply to patclash from comment #83) > > I couldn't try the Win32 build on the pc that have the bug, Nightly doesn't > > start; > > I got the message again (same as Comment#69) : "Couln't load XPCOM" > > Milan, do you know what's going on with this? Installation path too long?
Flags: needinfo?(milan)
(In reply to Milan Sreckovic [:milan] from comment #87) > (In reply to Seth Fowler [:seth] from comment #85) > > (In reply to patclash from comment #83) > > > I couldn't try the Win32 build on the pc that have the bug, Nightly doesn't > > > start; > > > I got the message again (same as Comment#69) : "Couln't load XPCOM" > > > > Milan, do you know what's going on with this? > > Installation path too long? I don't do an install (I just unzip the zip file) If I take the last official Nightly in the same folder , it start normally (but with the bug ;))
This was also reported as one of the symptoms in bug 1184618. @ssimon, do you have any new information you can add to this bug? If possible, could you try to find a regression window?
Whiteboard: [gfx-noted] → [gfx-noted][betabreakers-41]
See Also: → 1184618
The regression range is in comment #18. So he needs to just test these 2 builds.
(In reply to Loic from comment #90) > The regression range is in comment #18. So he needs to just test these 2 > builds. Then why is this marked as regressionwindow-wanted? What is *actually* needed to move this bug forward? Seth, maybe you can help clear this up.
Flags: needinfo?(seth)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #91) > (In reply to Loic from comment #90) > > The regression range is in comment #18. So he needs to just test these 2 > > builds. > > Then why is this marked as regressionwindow-wanted? What is *actually* > needed to move this bug forward? Seth, maybe you can help clear this up. I think we can clear regressionwindow-wanted, and I'll do so now. We know that bug 1124084 is the cause, but we don't understand exactly what's going on here. (Obviously, downscale-during-decode is working fine for the vast majority of users.) Nobody at Mozilla has been able to reproduce this issue so far. We've ordered a Radeon 9250 to see if that will enable us to reproduce locally, but we haven't received it yet. TWP, at the moment you're still the best hope for moving this bug forward. If you get a chance, could you please retest the latest build I posted with "layers.offmainthreadcomposition.enabled" set to "true" and "image.downscale-during-decode.enabled" set to "true"? patclash, I'll try to reproduce your problem with the Windows builds today and see if I can figure why they're not working for you.
Flags: needinfo?(seth) → needinfo?(pay_me.gold)
Keywords: regressionwindow-wanted
Thanks for following up so quickly Seth. We also have someone from Betabreakers with a system that can reproduce the issue (ssimon - cc'd in this bug). Is there something they could do to help?
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #89) > This was also reported as one of the symptoms in bug 1184618. @ssimon, do > you have any new information you can add to this bug? If possible, could you > try to find a regression window? I have no new information other than the bug I logged here https://bugzilla.mozilla.org/show_bug.cgi?id=1184618 Is there any additional testing you would like me to perform?
It would be nice if you could verify the regression range posted in the previous messages. If you are familiar with the tool Mozregression, it's easy to perform, or you can do that manually as I explained in comment #14. IMHO, you might start by verifying the 2 builds from comment #18. If that doesn't fit with your testing (not the last good build and/or not the first bad build), run a dichotomy test.
(In reply to Loic from comment #95) > It would be nice if you could verify the regression range posted in the > previous messages. > > If you are familiar with the tool Mozregression, it's easy to perform, or > you can do that manually as I explained in comment #14. > > IMHO, you might start by verifying the 2 builds from comment #18. If that > doesn't fit with your testing (not the last good build and/or not the first > bad build), run a dichotomy test. I'm assuming you would like these tests run on the system Geico (a Toshiba portege running Windows XP) as that was the system that bug 1184618 was reported on.
(In reply to ssimon from comment #96) > I'm assuming you would like these tests run on the system Geico (a Toshiba > portege running Windows XP) as that was the system that bug 1184618 was > reported on. Yes please, thanks.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #97) > (In reply to ssimon from comment #96) > > I'm assuming you would like these tests run on the system Geico (a Toshiba > > portege running Windows XP) as that was the system that bug 1184618 was > > reported on. > > Yes please, thanks. Okay. First I did a mozregression with a range of --good 2015-03-31 --bad 2015-04-02 based on the above comments. I did not see the issue ever occur with that range, and every build was "good". Next, I ran a mozregression with a range of --good 2015-04-01 --bad 2015-07-15. This is what I got at the end of going through inbound builds: 37:09.85 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :( 37:09.86 LOG: MainThread Bisector INFO Last good revision: 408e353d81a3 37:09.86 LOG: MainThread Bisector INFO First bad revision: e85ff3b95bd9 37:09.87 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=408e35 3d81a3&tochange=e85ff3b95bd9 My test was to go to flickr.com and observe the page while scrolling. Some builds had their tab crash when the display issue was observed. I hope this helps.
(In reply to ssimon from comment #98) > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=408e353d81a3&tochange=e85ff3b95bd9 Thanks, this range implicates bug 1124084 which is the same as above. > My test was to go to flickr.com and observe the page while scrolling. Some > builds had their tab crash when the display issue was observed. If you could, can you provide the IDs for the crash reports of these tab crashes? They should show up in about:crashes. Thanks.
Blocks: 1184618
> Blocks: 1184618 Note, I added bug 1184618 as blocked by this bug because the regression window is the same. These could very well be dupes but I'd like to keep them both open for now so we can retest once this one is fixed. Marking this as NEW since we have multiple people engaged on this bug who can reproduce the issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So the regression range gave in https://bugzilla.mozilla.org/show_bug.cgi?id=1180317#c19 is not correct?
(In reply to Loic from comment #101) > So the regression range gave in > https://bugzilla.mozilla.org/show_bug.cgi?id=1180317#c19 is not correct? Maybe, maybe not. That regression window is for mozilla-central while ssimon's is for mozilla-inbound. Inbound regression windows are usually far more precise as they're per checkin whereas Central windows are per-day. One does not necessarily invalidate the other. I can try to explain this in more detail offline if you'd like but I won't get into on this bug report.
Seth, would it help to have ssimon follow the instructions in comment 78 and post results similar to comment 79 for the flickr.com use case?
Flags: needinfo?(seth)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #103) > Seth, would it help to have ssimon follow the instructions in comment 78 and > post results similar to comment 79 for the flickr.com use case? Yeah, it'd be a big help if ssimon can indeed reproduce this. It'd be good to check the sites that are listed in this bug, and not just flickr, to make sure that everyone's hitting the same bug. ssimon should make sure that "image.downscale-during-decode.enabled" is set to "true" before starting his testing. Also, I wouldn't worry about "image.decode.retry-on-alloc-failure", as that seems to be causing crashing for people.
Flags: needinfo?(seth)
Sorry for the delay, our wireless is down and I'm forced to use public library access. I'll try to do the (re)testing this week.
Flags: needinfo?(pay_me.gold)
I have run mozregression and get to this inbound range (2015-05-06) https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=408e353d81a3&tochange=e85ff3b95bd9
(In reply to Seth Fowler [:seth] from comment #104) > (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #103) > > Seth, would it help to have ssimon follow the instructions in comment 78 and > > post results similar to comment 79 for the flickr.com use case? > > Yeah, it'd be a big help if ssimon can indeed reproduce this. It'd be good > to check the sites that are listed in this bug, and not just flickr, to make > sure that everyone's hitting the same bug. ssimon should make sure that > "image.downscale-during-decode.enabled" is set to "true" before starting his > testing. Also, I wouldn't worry about "image.decode.retry-on-alloc-failure", > as that seems to be causing crashing for people. ssimon, can you please take care of this as soon as possible?
Flags: needinfo?(ssimon)
Firefox 42.0a1 custom build testing, PER COMMENT #84 Some of the text below is a copy from prior test cycle. The order of preference reference is changed Per request these two preferences were set to true: - Set "image.downscale-during-decode.enabled" to true - Set "layers.offmainthreadcomposition.enabled" to true Test using three URL's https://www.reddit.com/r/firefox/ http://www.breitbart.com/ http://phys.org/ configuration 1) Check six preferences in about:config and ensure they are initially set to true. Set sixth preference (image.single-color-optimization.enabled) to FALSE A seventh preference was discussed, but it does not exist in my about:config list. image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false Test 1: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Failed, resized JPEG images are shown as torn or blue/black block image. http://www.breitbart.com/ Failed, resized JPEG images are shown as torn or blue/black block image. http://phys.org/ Mixed Result, Some resized JPEG images are initially displayed correctly, but change to torn or blue/black block image. Other resized JPEG images are correctly displayed. Test 2: image.mem.surfacecache.trust-surfaces.enabled;false image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false General failure. Even this forum has flashing user icons (vertical bars icon box) Firefox tabs are unstable (flashing '+' sign and flashing tab border lines. This effect stopped immediately upon resetting (image.mem.surfacecache.trust-surfaces.enabled;) to true https://www.reddit.com/r/firefox/ Failed, resized JPEG images are shown as torn or blue/black block image. Icons and resized JPEG's also flash. http://www.breitbart.com/ Failed, resized JPEG images are shown as torn or blue/black block image. Icons and resized JPEG's also flash. http://phys.org/ Failed, resized JPEG images are shown as torn or blue/black block image. Icons and resized JPEG's also flash. Test 3: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;false image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Failed, resized JPEG images are shown as torn or blue/black block image. Initially display correctly and then fail. http://www.breitbart.com/ Failed, resized JPEG images are shown as torn or blue/black block image. Initially display correctly and then fail. http://phys.org/ Mixed Result, Some resized JPEG images are initially displayed correctly, but change to torn or blue/black block image. Other resized JPEG images are correctly displayed. Test 4: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;false image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Failed, resized JPEG images are shown as torn or blue/black block image. Initially display correctly and then fail. http://www.breitbart.com/ Failed, resized JPEG images are shown as torn or blue/black block image. Initially display correctly and then fail. http://phys.org/ Mixed Result, Some resized JPEG images are initially displayed correctly, but change to torn or blue/black block image. Other resized JPEG images are correctly displayed. Test 4: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;false image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false This change caused an immediate restoration (without reloading URL's) and correct display of all scaled JPEG images. https://www.reddit.com/r/firefox/ Success, all scaled JPEG images display correctly http://www.breitbart.com/ Success, all scaled JPEG images display correctly http://phys.org/ Success, all scaled JPEG images display correctly Test 5: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;false image.single-color-optimization.enabled;false This change caused an immediate FAILURE, with all scaled JPEG's becoming corrupted (without reload of ULR). It also crashed all tabs except the tab for about:config, forcing me to close each tab and re-open it. https://www.reddit.com/r/firefox/ Failed, all tabs (except about:config) crashed and could not be successfully re-opened. http://www.breitbart.com/ Failed, all tabs (except about:config) crashed and could not be successfully re-opened. http://phys.org/ Failed, all tabs (except about:config) crashed and could not be successfully re-opened. THIS IS A RE-RUN OF TEST 1: Test 6: image.mem.surfacecache.trust-surfaces.enabled;true image.optimize.enabled;true image.downscale-during-decode.unlock;true image.downscale-during-decode.allow-scaling;true image.downscale-during-decode.only-if-scaling;true image.single-color-optimization.enabled;false https://www.reddit.com/r/firefox/ Failed, all tabs (except about:config) crashed and could not be successfully re-opened. http://www.breitbart.com/ Failed, all tabs (except about:config) crashed and could not be successfully re-opened. http://phys.org/ Same Mixed Result as in Test 1:, Some resized JPEG images are initially displayed correctly, but change to torn or blue/black block image. Other resized JPEG images are correctly displayed.
Using the Geico system (a Toshiba portege running windows XP), and Firefox 40 beta: The default value of image.downscale-during-decode.enabled is TRUE flickr.com - same issues as before, no images are displaying correctly reddit.com/r/firefox - thumbnail preview images associated with posts on this subreddit are not displaying correctly, however ads served on the right sidebar seem to be displaying correctly. breitbart.com - some images display correctly, but just about everything below "Now Playing on BREITBART TV" has the display issue - all the story preview images are black. phys.org - Most of the main content actually looks okay, but scrolling down a little, the "More News Stories" widget on the right side of the page seems to have all the thumbnail preview images as black squares. Just about every thumbnail displayed on the right half of the page is a black square. Even one of the ads has this issue. There are a few images that display correctly. The, with image.downscale-during-decode.enabled manually set to FALSE: flickr.com, breitbart.com, reddit.com/r/firefox, phys.org - all these sites display without issues. None of the issues described above occur with this setting set to false. Sorry for the delay on this. There was a request for crash reports, but the crashes I saw occurred while using the mozregression tool, and they don't seem to be displayed in the about:crashes page. No crashes were observed today while testing this.
Flags: needinfo?(ssimon)
TWP, thank you very much for these detailed test results! There are some interesting clues here. Could you confirm one thing for me? You said that when you set "image.downscale-during-decode.only-if-scaling" to false, all scaled JPEGs became corrupted immediately, right? Based upon what the pref does, I would have expected *all* JPEGs to become corrupted. Are you sure that only scaled JPEGs were corrupted after switching that pref to false?
Flags: needinfo?(pay_me.gold)
Also, I have one other question. With all the prefs at their default settings (making sure that "image.downscale-during-decode.enabled" is set to "true"), if you set "gfx.color_management.mode" to "0", does it have any effect on the problem?
I realized another potential issue - it looks like one thing that people experiencing this bug have in common is that their processor doesn't support SSE2. We may be incorrectly attempting to run SSE2 code on the downscale-during-decode code path even though we're running on hardware that doesn't support it. The build in comment 112 is designed to test this idea. Linux build here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-6f9a00f95ae4/try-linux/ Linux 64 build here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-6f9a00f95ae4/try-linux64/ Unfortunately it doesn't seem to be working for people, but just for completeness, there's a Windows build here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla.com-6f9a00f95ae4/try-win32/ To test this build, just run it and make sure that "image.downscale-during-decode.enable" is set to "true". If the black images are gone from the affected sites, then we know we've found the problem. (If not, it's worth trying setting "gfx.color_management.mode" to "0", as suggested in comment 111.)
(In reply to Seth Fowler [:seth] [:s2h] from comment #113) I have tried both linux and win32 and got XPCOM error message on both systems I have got a more explicit message on the linux shell : $ ./firefox/firefox -P nightly XPCOMGlueLoad error for file /home/antonin/Bureau/firefox/libmozgtk.so: libgtk-3.so.0: cannot open shared object file: No such file or directory Couldn't load XPCOM.
(In reply to Seth Fowler [:seth] [:s2h] from comment #113) > I realized another potential issue - it looks like one thing that people > experiencing this bug have in common is that their processor doesn't support > SSE2. We may be incorrectly attempting to run SSE2 code on the > downscale-during-decode code path even though we're running on hardware that > doesn't support it. The build in comment 112 is designed to test this idea. > > > Unfortunately it doesn't seem to be working for people, but just for > completeness, there's a Windows build here: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mfowler@mozilla. > com-6f9a00f95ae4/try-win32/ > > To test this build, just run it and make sure that > "image.downscale-during-decode.enable" is set to "true". If the black images > are gone from the affected sites, then we know we've found the problem. > > (If not, it's worth trying setting "gfx.color_management.mode" to "0", as > suggested in comment 111.) This build does'nt work for me ; same message : "Couldn't load XPCOM" PS : Yes the machine with the bug as a SSE processor (not running SSE2)
I'd love if we could figure out this "Couldn't load XPCOM" issue - Tonin, patclash, I don't understand why you're getting this error. As an example, I just downloaded "firefox-42.0a1.en-US.win32.zip" from the link above, extracted it to my desktop, opened up the resulting folder and double-clicked on "firefox.exe", and Firefox started right up. (I had to click through a security dialog since try builds aren't signed.) That's what you're doing, too, right? Milan suggested above that "Couldn't load XPCOM" could be caused if the directory you're running firefox.exe from has a path that's too long. Maybe it's worth trying extracting the zip to "C:\firefoxtest" or something like that.
(In reply to Tonin from comment #114) > (In reply to Seth Fowler [:seth] [:s2h] from comment #113) > I have tried both linux and win32 and got XPCOM error message on both systems > > I have got a more explicit message on the linux shell : > $ ./firefox/firefox -P nightly > XPCOMGlueLoad error for file /home/antonin/Bureau/firefox/libmozgtk.so: > libgtk-3.so.0: cannot open shared object file: No such file or directory > Couldn't load XPCOM. This case may be a little different. Firefox Nightly recently switched from GTK2 to GTK3. Maybe you don't have GTK3 installed?
A coworker suggested that the people who are getting "Couldn't load XPCOM" on Windows may not have msvcr120.dll installed on your system. You can get it by installing the package available here: http://www.microsoft.com/en-us/download/details.aspx?id=40784
(In reply to Seth Fowler [:seth] [:s2h] from comment #116) > I'd love if we could figure out this "Couldn't load XPCOM" issue - Tonin, > patclash, I don't understand why you're getting this error. > > As an example, I just downloaded "firefox-42.0a1.en-US.win32.zip" from the > link above, extracted it to my desktop, opened up the resulting folder and > double-clicked on "firefox.exe", and Firefox started right up. (I had to > click through a security dialog since try builds aren't signed.) That's what > you're doing, too, right? > > Milan suggested above that "Couldn't load XPCOM" could be caused if the > directory you're running firefox.exe from has a path that's too long. Maybe > it's worth trying extracting the zip to "C:\firefoxtest" or something like > that. I just try with extracting in a folder "C:\Nightlytest" and it is the same :(
(In reply to Seth Fowler [:seth] [:s2h] from comment #118) > A coworker suggested that the people who are getting "Couldn't load XPCOM" > on Windows may not have msvcr120.dll installed on your system. You can get > it by installing the package available here: > > http://www.microsoft.com/en-us/download/details.aspx?id=40784 I have msvcr120.dll installed; I reinstall it , reboot the PC and the Try build won't start with the same message :( (as I've said in comment#88, the last official Nightly build work)
(In reply to patclash from comment #120) > I reinstall it , reboot the PC and the Try build won't start with the same > message :( > (as I've said in comment#88, the last official Nightly build work) Thanks for checking! I'm sorry it still doesn't work; that's frustrating.
ssimon, since you've been able to reproduce this, could you try the build in comment 113 and see if it fixes the problem for you? (And if that doesn't work, check the "gfx.color_management.mode" idea mentioned at the bottom of comment 113 as well.)
Flags: needinfo?(ssimon)
(In reply to Seth Fowler [:seth] [:s2h] from comment #117) XPCOM issue Most of the time, I run a old linux (2011), but I have also a recent one (2014). The latest is shipped with gtk+3.0, and there is no more XPCOM error message. old# rpm -qa | grep gtk+ libgtk+-x11-2.0_0-2.24.5-3-mdv2011.0.i586 libgtk+2.0_0-2.24.5-3-mdv2011.0.i586 gtk+2.0-2.24.5-3-mdv2011.0.i586 new# rpm -qa | grep gtk+ gtk+2.0-2.24.22-3.mga4 libgtk+3_0-3.10.6-4.1.mga4 gtk+3.0-3.10.6-4.1.mga4 libgtk+-x11-2.0_0-2.24.22-3.mga4 libgtk+2.0_0-2.24.22-3.mga4 ---------------------------------------- I have also looked for winXP : - small path c:\firefox\firefox.exe ; - tried msvcr120.dll copied, installed from microsoft link (http://download.microsoft.com/download/A/4/D/A4D9F1D3-6449-49EB-9A6E-902F61D8D14B/vcredist_x86.exe) => No change, still XPCOM error message Maybe installing GTK+3.0 on Win XP could help... but I did not. http://www.gtk.org/download/win32_tutorial.php
(In reply to Seth Fowler [:seth] [:s2h] from comment #113) SSE2 not supported issue test of the build #113 "image.downscale-during-decode.enable" is set to "true" the black images are still there (https://www.google.fr/search?q=firefox&tbm=isch) trying setting "gfx.color_management.mode" to "0" (#111) the black images are still there
(In reply to Seth Fowler [:seth] [:s2h] from comment #122) > ssimon, since you've been able to reproduce this, could you try the build in > comment 113 and see if it fixes the problem for you? (And if that doesn't > work, check the "gfx.color_management.mode" idea mentioned at the bottom of > comment 113 as well.) I am also getting the "Couldn't load XPCOM" message when attempting to launch the windows build linked in comment #113. I installed the .exe to C:\ffnew\ and launched it from command line. I am running Windows XP Tablet edition on the Toshiba Portege known as Geico.
Flags: needinfo?(ssimon)
I'm downloading the build in comment #113. Will test with 'image.downscale-during-decode.enable' set to true and post test result
Flags: needinfo?(pay_me.gold)
Test Results: Per comment #113 set 'image.downscale-during-decode.enable' to true Test URLs: http://www.breitbart.com/ https://www.reddit.com/r/firefox/ http://www.breitbart.com/ Success: All three of these test URLs display all scaled JPEG images correctly. I also tested preference: Reset 'image.downscale-during-decode.enable' to true 'gfx.color_management.mode' setting it to '0' (original value '2') Success: All three of these test URLs display all scaled JPEG images correctly. I then set 'image.downscale-during-decode.enable' to false and left 'gfx.color_management.mode' setting as '0' (original value '2') Success: All three of these test URLs display all scaled JPEG images correctly. I then set 'image.downscale-during-decode.enable' to true reset 'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. I then set 'image.downscale-during-decode.enable' to false reset 'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Since these result conflict, I suspect that even reloading the URL using Shift-F5 does not flush the cached images. I will shut down Firefox and try this again. I will post again in a minute.
NOTE: Previous comment lists a duplicate test URL. The actual URL's are below, used in both test runs. Restarted Firefox using the build from comment #113 Test URLs: http://www.breitbart.com/ https://www.reddit.com/r/firefox/ http://phys.org/ Settings: 'image.downscale-during-decode.enable' to false 'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 2: 'image.downscale-during-decode.enable' to true 'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 3: - Set "image.downscale-during-decode.enabled" to true - Set "layers.offmainthreadcomposition.enabled" to true - Set -'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 4: testing an addition preference 'layers.offmainthreadcomposition.enabled' - Set "image.downscale-during-decode.enabled" to true - Set "layers.offmainthreadcomposition.enabled" to true - Set -'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 5: - Set "image.downscale-during-decode.enabled" to false - Set "layers.offmainthreadcomposition.enabled" to true - Set -'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 6: - Set "image.downscale-during-decode.enabled" to true - Set "layers.offmainthreadcomposition.enabled" to false - Set -'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Test 7: - Set "image.downscale-during-decode.enabled" to false - Set "layers.offmainthreadcomposition.enabled" to false - Set -'gfx.color_management.mode' back to the original value '2' Success: All three of these test URLs display all scaled JPEG images correctly. Conclusion: Inconclusive, I can't reproduce the problem using these settings.
TWP, Tonin, ssimon, thanks for the additional testing. TWP, it sounds like with the build from comment 113 you could no longer reproduce the problem, which strongly suggests that your problem was caused by running SSE2-specific code on your machine, which doesn't support SSE2. Tonin, you could still reproduce the problem, even with the build from comment 113. I suspect that that means that your problem actually has a different cause. I was finally able to get my hands on a machine that reproduces the problem (thanks ssimon!) so tomorrow I will investigate further.
Depends on: 1189593
Depends on: 1190607
Just to say this bug is fixed in Firefox 40.0* (current release) , in the fist Beta 41.0 and in the last Aurora 42.0 update (Do to the bug 1189593 fixed) I have reset the "image.downscale-during-decode.enabled" value to false with no more issue ;)
I give a tentative confirmation to patclash's post. 41.0a2 does appear to fix the bug.
I don't think we will take a fix for 40, untracking it.
status-firefox40: affected → wontfix
Seth, based on comment 130 and 131, could we resolve this bug as fixed due to bug 1189593? Thanks.
Flags: needinfo?(seth)
Thanks so much for verifying the fix, everyone! I'll go ahead and resolve this, per comment 133.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(seth)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: