views:

44

answers:

1

I'm designing/building a site, and like a good little developer I've been keeping an eye on how things render in all the popular browsers - the current versions of Firefox, Chrome, Safari (for Windows) and Chrome, and Internet Explorer (8, not the 9 preview).

Anyway, everything looked absolutely fine in Chrome to me, but a friend of mine who has been giving me some feedback told me "oh, btw, your site renders horribly in Chrome." I gave him the standard "works on my machine" response, and he replied that he thought it must be an extension problem.

He gave me a short list of the popular extensions he uses, and after a bit of trial and error I discovered the problem lies with AdBlock. I won't bore you too much with the details of the actual rendering problem, but we noticed something odd. It wasn't that AdBlock was blocking something on the page, but that the mere presence of AdBlock in Chrome was causing the problem. I know this because the problem persists even when a) I pause AdBlock, and b) when I specifically exclude that page/site from being AdBlocked.

I've since fixed the problem (I had noticed it earlier in a Firefox 3.0 "BrowserShot", but fixed the bug inside FireBug only - I hadn't applied it to the real copy yet), but it has left me wondering if there are other issues I should be aware of.

It doesn't seem to be a matter of Quirks vs. Standards Mode either. document.compatMode still shows "CSS1Compat" (Standards Mode), and when I remove the doctype definition to trigger quirks mode, the site still renders correctly (though with some padding changed in places - nothing to worry about).

Has anyone noticed this problem before? Does AdBlock fundamentally change the way Chrome renders pages, even if it's not active on that specific site?


Edit #1:

It gets weirder. I tried to create an example, but it wouldn't render improperly for some reason. Ultimately, I copied the original (i.e. failing) html into a new file, and threw the entire CSS file into a <style> tag in the <head> of the document. It still worked.

A bit of trial and error, and I've determined that the problem only exists when including css via <link rel="stylesheet"> but not via <style>.

Could someone please explain what's happening here?


Edit #2:

Here is the code I'm working with:

HTML:

<!DOCTYPE html>
<html>
  <head>
    <title>Demo</title>
    <meta charset="UTF-8">
    <link rel="stylesheet" type="text/css" href="style.css" />
  </head>
  <body>
    <div id="outer">
      <img src="placeholder.png" width="150px" height="150px" />
      <div id="inner">
        <h1>Test</h1>
        <p>Lorem ipsum blah blah blah</p>
      </div>
    </div>
  </body>
</html>

 

CSS:

    #outer {
      border: 1px solid #000;
      width: 700px;
    }

    #inner {
      float: right;
      width: 540px;
    }

If you'd like to try this out for yourself, I've put some files on my server:

A: 

It seems to be a problem in the way Chrome reflows content after css has been modified - you can reproduce the exact same rendering by following these steps:

  1. Disable Adthwart, reload chrome.
  2. Load the page (any of the two).
  3. Go in the Chrome inspector - select the div#inner element.
  4. Deactivate, then reactivate, the float: right; CSS attribute.

It would be a good idea to file a bug report, if it does not already exist - it's either a WebKit or a Chrome bug.

jhominal
Damn. I *just* finished filing a report with adblockforchrome. I guess I'll have to file another. Any idea a) why this only happens when adblock is installed, and b) why it only happens with `<link>` and not `<style>`?
AgentConundrum
Looks like this is webkit, not just chrome. I used the firebug lite bookmarket on safari and was able to repro this.
AgentConundrum
Here is my guess: b) With `<link>`, the CSS properties must be loaded after a http request, whereas with `<style>`, these CSS properties are available immediately to WebKit; a) Adblock operates by adding CSS styles - I'd guess that in the case with Adblock/`<link>`, the Adblock CSS is loaded first, the `<link>` CSS second, which triggers the bug. (In the 3 other cases, the `<link>` or `<style>` CSS is loaded before any other.) Feel free to add a link to the bug report when it is filed.
jhominal
@jhominal: [Here](https://bugs.webkit.org/show_bug.cgi?id=48235) is the bug report.
AgentConundrum