Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 183 users
Status: Fixed
Owner:
Closed: Feb 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Background images that were hidden, and then exposed sometimes disappear
Reported by a...@mixedmedialabs.com, Jan 24 2012 Back to list
Chrome Version       : 17.0.963.38 beta
URLs (if applicable) :  http://www.facebook.com/OneSchoolApp?sk=app_304039862941303
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: ok
  Firefox 4.x: ok
       chrome 16.0.912.75: ok 

What steps will reproduce the problem?
1. Go to http://www.facebook.com/OneSchoolApp?sk=app_304039862941303
2. click through the tabs: iPhone -> Android -> Windows Phone 7 -> Android -> iPhone

What is the expected result?
The image of the phone should be visible 

What happens instead?
Sometimes the image of the phone disappears 

Please provide any additional information below. Attach a screenshot if
possible.

 
good.png
431 KB View Download
bad.png
442 KB View Download
We are seeing this as well and it is a serious problem for us. We use a sprited background image for the pushpins on our map (GMaps v3.6). It is easy to reproduce this problem on our search page and we have had a number of users write in about it already.

To reproduce:

1. Go to 

http://www.redfin.com/homes-for-sale#!lat=37.764135900998525&long=-122.4826948656746&market=sanfrancisco&sf=2&v=6&zoomLevel=12

(See screenshot 1)

2. Click on a home if one is not already selected.
3. Click on the View Details button in the sidepane.
4. Click on the browser's back button.

Actual: The pushpins and other elements from the background image sprite do not reappear.

Expected: The sprited images reappear.

This behavior DOES NOT reproduce on: Chrome 16, FF10, Safari 5.1

The behavior DOES reproduce on: Chrome 17, Chrome 18.
Screen Shot 2012-02-10 at 1.10.32 PM.png
591 KB View Download
Screen Shot 2012-02-10 at 1.10.18 PM.png
586 KB View Download
Confirmed reproduced on 4 different Macs running Chrome 17. But Windows running Chrome 17 is fine.
Comment 3 by Deleted ...@, Feb 11 2012
The same thing happens on this website: http://renlakrids.dk/

Clicking between the different pages, some times the tin images disappear. on Mac OS X 10.7 , Chrome 17.
Cc: senorblanco@chromium.org
Labels: -Area-Undefined Area-Internals
In the past I've used a trick similar to what Fuchs says here, but its clearly a loose workaround
http://mir.aculo.us/2011/12/07/the-case-of-the-disappearing-element/

senorblanco, have any idea on this? This is currently repro'able in stable.
Cc: reed@chromium.org caryclark@chromium.org tomhud...@chromium.org
No idea off the top of my head.  A reduced test case would be great, but perhaps someone can bisect-builds with the given repro steps.
I narrowed it down to here with bisect-builds:

Downloading revision 108959...
Trying revision 108959...
Revision 108959 is [(g)ood/(b)ad/(q)uit]: g
Downloading revision 108963...
Received 32087119 of 32087119 bytes, 100.00%
Trying revision 108963...
Revision 108963 is [(g)ood/(b)ad/(q)uit]: b
You are probably looking for build 108963.
WEBKIT CHANGELOG URL:
http://trac.webkit.org/log/trunk/?rev=99453&stop_rev=99399&verbose=on
CHANGELOG URL:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=108959:108963
Built at revision:
http://src.chromium.org/viewvc/chrome?view=rev&revision=108963

Unfortunately, there's a webkit roll in there, and I don't have a source build of Chromium handy to be able to bisect based upon changes in webkit.

This is based upon testing with:
https://www.facebook.com/VEVO?sk=app_304039862941303
(an App.net tab that doesn't require you to Like anything to see it)
Comment 7 by Deleted ...@, Feb 13 2012
This happens to us and is very serious. We opened this bug: http://code.google.com/p/chromium/issues/detail?id=113774
Comment 8 by Deleted ...@, Feb 13 2012
Also the mir.aculo.us workaround does not fix the issue
Comment 9 by das...@gmail.com, Feb 14 2012
The mir.aculo.us workaround does not fix the issue for me either.  Like everyone, the problem is only with Chrome 17 and 19 on Mac OSX, Chrome on Windows works fine.

It is happening on my pages here:
http://dealsfortherich.com/drop/
You can see the error by changing pages using the left and right arrow keys, (which are mapped to the same function that is called when clicking "next page").  However, clicking the button to change pages doesn't seem to cause the problem so much.  It's usually when changing pages (with the right arrow key) combined with fast scrolling that causes the problem.  
Comment 10 Deleted
Having the same issue here: http://ttpf.wingardcreative.com

The navigation background image is fine, but if you click one of the categories to navigate, half the time it disappears. If I "inspect element" and then modify any element, the background re-appears fine. It's ONLY the background-image.
We're seeing this issue at http://wordsquared.com as well - css background-images are disappearing when a previously hidden image is shown, as well as when we change the background-image property for a visible element.  Appears to be OS X-only as well.  Reproducible in Chrome 17 and 18 on OS X.
This is almost certainly a duplicate of  issue 109049 .
This appears to be a dupe of  issue 70268  and  issue 109049 , both of which may be related to WebKit bug https://bugs.webkit.org/show_bug.cgi?id=73760.

Hopefully we can get these three bugs merged and some attention paid to this issue :)
I have a fix for this issue, but what I really need to move this forward is a reliable, small testcase.

I'm planning on working on a reduction tomorrow, but if anyone has a good starting point, I'd love to see it.
I've been working on a reduction, but haven't had any luck so far.  I've been focused on the revealing of previously hidden images.  I'm going to try adding spriting into the mix next, to see if that matters.  
@Japhet If you could send out the patch, maybe we could use that to develop a reduced test case?
I created a small testcase. It doesn't show the bug all the time. Try refreshing and clicking the links at the bottom. Eventually you will only see the background-color, not the image. When you use the Developer Tools and toggle the missing background-image it is visible again.

http://down-to-mars.tv/temp/testcase/
Comment 19 by das...@gmail.com, Feb 15 2012
Regarding the testcase at http://down-to-mars.tv/temp/testcase/, the error happens more often if you try to switch the image before the current fadeIn is complete.  Try clicking the different links very quickly.


Comment 20 by Deleted ...@, Feb 15 2012
This temporary solution works, but it's not pretty: http://blog.andrewcantino.com/blog/2012/02/15/fixing-the-chrome-background-refresh-bug/
Comment 21 Deleted
Comment 22 by das...@gmail.com, Feb 15 2012
The temporary solution posted by Andrew Cantino (comment 20) works perfectly.
My pages are transitioning perfectly now!
http://dealsfortherich.com/drop/
Thanks Andrew. 
I was able to repro with the down-to-mars code.  To make it simpler for developers, I converted that repro code to be self-contained (no external images, no jquery dependency, etc.)  Please find attached.  I also added an "automate!" link, which will start rotating the images every 400 ms.
one.html
286 KB View Download
I've put the fix in place at http://ttpf.wingardcreative.com/, but it doesn't seem to be working. Granted, I'm not the greatest at Javascript, so I may have implemented it wrong. It's in the navigate.js file. When a user clicks on a category on the toolbar, it should fade out and fade back in. Right now just the toolbar content fades in (and the background stays hidden).
Comment 25 by das...@gmail.com, Feb 16 2012
For cry...s@wingardcreative:
Instead of, or maybe in addition to, putting: 
  refreshBackgrounds("div#toolbar");  
in your showNavBar() function, you should put it  below
  $('#toolbar').fadeIn(); 
(which is in your else statement inside your click function)


Perfect! Thanks, das...@gmail.com (and thanks to Andrew Cantino for the fix).
Comment 27 Deleted
Comment 28 by das...@gmail.com, Feb 16 2012
Cool, it looks like it's working but you probably also want to add 
  refreshBackgrounds("div#logo");
  refreshBackgrounds("div#mosh-presents");
b/c the background images are disappearing there too.
Cc: japhet@chromium.org
Per Comment #17, attached is the patch that should resolve this.
purge.txt
588 bytes View Download
Got it!
japhet's patch in comment #29 fixes the problem on redfin.com and in Michael's test case from comment #23.

Others might test this build as well to confirm that it resolves the problem: http://dl.dropbox.com/u/8497522/japhet-fix.zip
#31 your build fixed it for me
Here's the other patch I have, it appears to fix both chrome.angrybirds.com and redfin.com, haven't tried elsewhere yet.
sci.txt
1.1 KB View Download
Comment 34 by a...@chromium.org, Feb 17 2012
This patch (the one in comment 33) looks like it fixes the cursor issue in  bug 111027 .
I confirm that japeth's sci.txt patch fixes redfin.com. It also fixes michael's one.html test case from comment #23, as well as the cursor  bug 111027 .

Here's a copy of my build: http://dl.dropbox.com/u/8497522/chrome-mac-2.zip
Labels: -Area-Internals Area-WebKit
Owner: japhet@chromium.org
Status: Started
Fix landed in http://trac.webkit.org/changeset/108100.

I'll be merging this to beta and stable on Monday as long as nothing disastrous happens in the weekend canaries, so the fix should be in the next update.
Cc: kbr@chromium.org abarth@chromium.org mikelawther@chromium.org marshall@chromium.org
 Issue 109049  has been merged into this issue.
 Issue 70268  has been merged into this issue.
Cc: sky@chromium.org rayanna@chromium.org gregsimon@chromium.org a...@chromium.org tha...@chromium.org
 Issue 111027  has been merged into this issue.
Comment 40 by a...@chromium.org, Feb 20 2012
 Issue 108358  has been merged into this issue.
Comment 41 by a...@chromium.org, Feb 20 2012
 Issue 114504  has been merged into this issue.
Comment 42 by a...@chromium.org, Feb 20 2012
 Issue 109918  has been merged into this issue.
Status: Fixed
I just verified that this appears to be fixed on Canary.

Merged to Beta: http://trac.webkit.org/changeset/108251
Merged to Stable: http://trac.webkit.org/changeset/108253
The fix should be making its way to all channels in the next update, so marked this as fixed.

 Issue 115035  has been merged into this issue.
Comment 45 by k...@google.com, Feb 22 2012
 Issue 113861  has been merged into this issue.
Comment 46 by k...@google.com, Feb 22 2012
 Issue 113417  has been merged into this issue.
Hi,

Can you tell me when is this fix being released?

I'm running Coogle Chrome 17.0.963.56 and I'm still seeing this issue.

Thank you.
Here's a video of issue on a dupe http://code.google.com/p/chromium/issues/detail?id=115272
Comment 49 by a...@chromium.org, Feb 28 2012
 Issue 115272  has been merged into this issue.
When is this fix supposed to be available?
Checking the Chrome Releases Blog http://googlechromereleases.blogspot.com/search/label/Stable%20updates and typing release dates since September into a spreadsheet, it appears that Stable releases go out on average every 14 days, excluding Chromebook releases. The median interval is 16 days. The largest interval was 27 days, between Nov 16 and a major release on Dec 13.

The last stable release was Feb 15, so we're due for a release any day now.

In the absolute worst case, Google might decide not to schedule another release for Chrome 17. In that case, we'd expect the fix in Chrome 18, which should arrive 40 to 60 days after the release of Chrome 17. That was on Feb 8, so we'll definitely have the fix by early April. :-p

Now, please stop asking when the release will be available! The release managers don't read bug reports anyway; the release will go out when it goes out.
Hi Dan,

Thank you for the stats and insights.

The reason I asked was simply to know if needed to find a workaround or not.

Cheers.
 Issue 113631  has been merged into this issue.
 Issue 113556  has been merged into this issue.
 Issue 113548  has been merged into this issue.
Appear to be fixed on today release: 17.0.963.65, thanks ! :-)
Comment 57 by Deleted ...@, Apr 13 2012
I think this issue is still present if background-attachment:fixed is set.
Comment 58 by Deleted ...@, Jul 4 2012
This issue reappears since the last Chrome Update (Version 20.0.1132.47) on Mac OSx.
Comment 59 by Deleted ...@, Jul 9 2012
Confirmed.  Issue also reappeared in Chrome version 20.0.1132.47 on PC running Windows 7 Ultimate 64bit SP1.  Need to apply temporary fix as indicated in Comment 20 by and...@mavenlink.com, Feb 15, 2012.
If you are seeing this problem on a platform other than mac, it's not a regression of this exact issue. Please feel free to open a new bug with repro steps and point me at it.
Comment 61 by Deleted ...@, Jul 24 2012
This issue is also back for us on 20.0.1132.57 on OS X. Quite frustrating.
As mentioned in comment 60, please file a new bug for the regression and then mention the bug # here.
Any indication as to when this particular bug will be addressed? Thanks!

michael.spellacy: This particular bug was fixed. If there was a regression with identical symptoms, please file a new bug and mention the bug # here, as said above a few times already.
Perhaps this bug should have Restrict-EditIssue-Commit
er, restrict commenting to committers
That's great. When was this particular bug fixed? We just noticed a similar issue a couple of weeks ago. If it has been fixed within that time in a new release then we probably no longer have a problem. Thanks for your time!
I would suggest that since a number of people are reporting that the bug is not fixed... then perhaps it is not fixed?  I for one see recurrences of this situation in about 1 in 100 page loads.
Should be fixed in chrome 19 or later.
in chrome 21.0.1180.60 m for windows Seven i notice this bug when loading page from a server in local network.

The pages as been created using ext.js framework and 
when this bug appear some buttons in my page does not appear 

Reloading the page does not help, is necessary to close and restart chrome. 

Restarting chrome all is working fine for some time then the problem appear again. 
Labels: Restrict-EditIssue-Contributer
As has already been mentioned multiple times, I would be quite happy to look at this issue for you, but please open a new bug and provide as much information as possible (version of chrome, OS and version, website where you see it or a reduced test case, etc). Based on the descriptions provided, the reports mentioned in the last few weeks are likely a similar bug, but not this one.

Feel free to email me directly with the link to any bug you might open, as I'm restricting comments on this bug.
As you asked, I opened a new issue on this problem #143144
Thank you
Comment 73 by laforge@google.com, Oct 15 2012
Labels: -Restrict-EditIssue-Contributer Restrict-AddIssueComment-Commit
Project Member Comment 74 by bugdroid1@chromium.org, Mar 11 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 75 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment