Originally reported by @te-brian at http://drupal.org/node/610234#comment-2284736 - making it a separate issue here:

What I'm seeing is that when the overlay has finished fading in, some of the links are still kind of half-rendered. I am using Firefox 3.5 and I have seen something similar in jquery fade effects since upgrading to 3.5. As you can see some of the links are hazy and have a green tinge. This is what I sometimes see during the fade effect but this is the first time the poor rendering has "stuck" after the fade finished.

Relevant screenshot is at http://drupal.org/files/issues/overlay-links-rendering.jpg

CommentFileSizeAuthor
#4 655542-opacity-4.patch1 KBseutje
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

te-brian’s picture

Just wanted to confirm that with the latest HEAD, and with Firefox 3.5.5 I am seeing this. Again, I don't think this is due to overlay code, more of a JS in FF issue. I'll try to experiment some more and see if I can narrow down the conditions for this behavior. I am noticing that its not all anchors that this happens on, as I have never seen it on an anchor inside a header. <h2><a>This</a></h2>. I also have not noticed the problem in the breadcrumb.

seutje’s picture

can u see if u get the same behavior on active links? (<a class="active" href="foo">foo</a>) or any other text that isn't blue

te-brian’s picture

Did a few tests. I just added a few hand-coded links to the top of the "page" div in page.tpl.php.

Plain links with no class or wrapper were "blurred".

Links with an arbitrary class were "blurred".

Links with the active class were"blurred".

Links with the active psuedo class were"blurred".

Links inside an h2 were blurred.

A link with color #000 (black) was NOT blurred.
A link with color #f00 was blurred.
A link with color #fff was blurred (surprisingly, it was not white, but rather a blurry blue-green).

So, in the context of a link hand-coded into page.tpl.php, I dont see any real pattern other than that black links "work". Keep in mind that not all links are broken. Most links in the overlay do display properly, so these results merely rule out a few potential fixes, rather than point to "bad" links.

seutje’s picture

Status: Active » Needs review
FileSize
1 KB

try this, it won't change the state while fading in but it should fix the final loaded state

not rly sure why this was set to 0.9999 instead of 1, I'll try to backtrace this later tonight and see if I can poke the person that introduced it to see if this was some sort of workaround for a bug and if we can't find a different workaround

[edit] btw, I don't even see any fading occur on the iframe body, before or after attached patch [/edit]

seutje’s picture

hmm, seems to appear in the initial commit, guess I'll have to dig a lil deeper

Status: Needs review » Needs work

The last submitted patch failed testing.

te-brian’s picture

@seutje, sorry I missed this one earlier this week. I'll give it a try tonight or in the morning and report back.

Status: Needs work » Needs review

seutje requested that failed test be re-tested.

casey’s picture

Status: Needs review » Fixed

This is fixed per #174 in #615130: Overlay locks up the browser and consumes 100% of CPU for certain browsers/graphics cards/operating systems.

Anyone who can still reproduce it is free to reopen.

seutje’s picture

yea that patch seems to incorporate the same fix

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.