Chrome 22 breaks things | Hacker News Reader

Chrome 22 breaks things

chrisvalleskey.com

147 pointscvalleskey103 comments

for position: fixed and changed stacking contexts, you're likely running into this:

http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

Basically, the position: fixed on the parent of the span you're trying to put on top is now making the parent its own stacking context, which means that all children will be stacked relative to each other, not to the first absolutely or relatively positioned ancestor of the parent, as it was before.

The easiest fix is to set the z-index on the parent, since that will correctly stack it relative to its sibling (your other position: fixed element). The other way is to give the sibling that you want to be below the other content a negative z-index, since that will, again, specify it in the stacking context you want to affect. Both of these fixes should render correctly in older browsers (I believe).

This is annoying when it affects existing content, but it is part of the spec now (and it's apparently how mobile browsers have always rendered it).

for the float issue, I did find this:

http://code.google.com/p/chromium/issues/detail?id=133474

it may be a dupe of an older bug, but I got tired of looking.

It's worth noting that it does not render as stated in Firefox (Mac or Win) or IE9 (in IE9 or compatibility modes).

IE9 puts the entire h1 below the floated content. Firefox is partway between IE and Chrome and moves the "This" off to the right side but puts the rest of the h1 below the floated content. Safari is the only browser that renders like the "old" screenshot with floated content and the h1 overlapping (and I would bet this change was made at the webkit level, so webkit nightly and eventually safari will lay out like chrome).

I avoid floated content whenever possible, so I can't comment on which browser has the correct rendering. That every browser renders differently doesn't speak well for the state of the float spec, though :) It looks like it's the negative top margin of the element after the floated content that is the root of the disagreement, and that particular case may just be under- or unspecified.

What does the spec say? is there a bug opened already? or are all the browsers wrong and Chrome is right?

The spec says Chrome is right (was recently changed). Chrome is not the only browser. iOS browsers, the Android browser and Chrome for Android have always used the new behavior. The reason for the change is faster scroll performance, particularly on mobile.

Those are all webkit based browsers, so it seems normal that they'd all behave the same.

Well they did not. Until Chrome changed the behavior to comply with http://www.w3.org/TR/CSS21/zindex.html

The CSS 2.1 spec was last updated in 2011 and does not include any mention of this new stacking context behavior (which was only proposed on the CSS mailing list in May 2012 and has not yet made it into any spec).

No, they changed it to no longer comply with that spec, actually. Please do read the spec, not assume it says what the "html5rocks" marketing folks want it to say.

Really? Can you point to the spec change? Did I miss a working group decision on this somewhere? Last I checked, the discussion on this got nowhere, with WebKit folks claiming this change was needed to optimize stuff and Opera and Mozilla folks claiming that optimizing scrolling worked just fine without this behavior change...

http://www.w3.org/TR/CSS21/zindex.html

This has no such change. Try again.

How much content does this break? Was this discussed on one of the public mailing lists? If so, does anyone have a link to some relevant discussion? (I would love to hear the various positions regarding breaking existing content to bring an optimization used by browsers people generally consider to render things weirdly to all browsers.)

This was proposed here on the CSS WG public mailing list: http://lists.w3.org/Archives/Public/www-style/2012May/0473.h...

Yes, and no one other than WebKit folks seemed to feel it was particularly warranted. Which makes this deliberate spec violation all the more interesting to me. Nothing like sabotaging the standards process by deliberately trying to force the issue in the field when you fail to convince people as part of that process.

The upshot of the discussion was that this change is not needed to optimize things in non-WebKit UAs as far as anyone can tell. So the discussion sort of petered out, last I checked.

I've been seeing color abberations in text since my PC updated to Chrome 22. Most noticeable has been blue links showing up with a purple tint -- significantly different from the color showing in the Inspector. It's browser-wide, with extensions disabled -- I first noticed the change in link color on a Reddit comment thread, then saw it on Google Plus and my own website as well.

http://i.imgur.com/Wjay2.png

Has anyone else noticed this? I've been watching Google's "Past 24 Hours" search result and only one other person has talked about a similar problem; he's seeing the same thing but only on external monitors.

This is the first show-stopping Chrome bug for me... I can't work with a browser that won't display the colors I tell it to display when designing pages. Frustrating that I can't even get confirmation others are experiencing it.

Smells like subpixel aliasing?

I've noticed this as well, for blue links. It's really bugging me. Are you aware of a workaround?

Edit: I'm on a Mac, 10.7.5, FWIW

I haven't found one. I tried switching color profiles on my display, removing extensions, upgrading to Chrome Canary -- colors are still off.

There's new ICC support in Chrome 22. Perhaps that is interacting poorly with some setting in your system?

I think that change is only supposed to apply to rendering of certain images, not text. Regardless, I went down that avenue as much as I could, switching color profiles (as I mentioned) in my display settings and rebooting to see if there'd be any change.

It shouldn't be the issue since ICC was already supported by other browsers, and they're not showing this new text color abnormality, just Chrome.

http://code.google.com/p/chromium/issues/detail?id=146407

+1 This is probably very very subtle for most people to notice, but I'm seeing aswell and it's bugging me to no end. I'm pretty sure even the colors in the developer tools are off.

At first I thought it was just me seeing things, but surely enough a side by side comparison with firefox (15) revealed otherwise: http://i.imgur.com/N29QC.png

Additionally, Chrome 22 changed the behavior of -webkit-font-smoothing: antialiased so that the weight of fonts looks much different than it used to when this was enabled. It makes icon fonts look especially bad.

http://code.google.com/p/chromium/issues/detail?id=152304

I was going to say the same thing. I'm glad I'm not the only one who was bothered by this.

Well it is experimental for a reason.

As quoted from the bug report

> The webkit-font-smoothing css property is, contrary to the summary, still working. It is still respected, as no lcd font smoothing is being applied. However, the bug where it also affected the weight of the text as a side effect has been fixed.

Though it's worth noting they are looking into whether the purpose (and thus the function) of this particular property should be adjusted.

Is this a case where the bug presents a better solution than the intended design?

Your last sentence is reassuring that the developers appreciate this too.

It actaully doesn't have much to do with -webkit-font-antialiasing as a css extension, and much more to do with how chrome is handling font rendering in general. v22 was a big, big step backwards.

Designers and typographers are pissed. Even if it's "right" as the chromium devs seem to insist, it doesn't change the fact that fonts look like shit, and don't look like type designers intended them to render.

Without wishing to piggy back on this thread I feel its a good time to point out that this is exactly why enterprises stick with IE. People are risk averse in businesses.

Enterprise apps using IE have 1/100 of the design complexity of sites that are affected by these changes.

You'd be surprised. The amount of CSS/HTML that goes into your typical LOB application is quite large and the applications are typically orders of magnitude more complicated than "sites" as you mention. The piece of kit I work with has approximately 900 ASP.Net MVC views...

I just ran CLOC. We have 6.2 million lines of code in 14 different languages!

It's orders of magnitude more complicated, and generally for no good reason. There are often conflicting CSS rules, or 100 lines of cruft when 10 lines might work just fine.

And yes, things break all the time, often for unknown or unexpected reasons, and it's sometimes close to impossible to figure out why and fix the bug.

The enterprise software world is scary.

As someone who worked on an internal NHS website I can affirm this. Rather than use the same CSS and HTML for a form no matter which page it appeared on, the original coders had re-written it from scratch every single time, with slight differences (some intentional, some bugs) between them all.

Oh, and the entire site didn't work in IE6, it was developed / tested entirely targeting Firefox, despite the IE6 requirement being in the spec (and it ONLY needing to work with IE6).

Are those problems really specific to enterprise software?

This "Enterprise Software" label doesn't make sense at all, anyway.

Trust me, it does. It means "business software which sucks to an incomprehensible degree."

Some of the most advanced CSS and Javascript I have seen for the first time in Enterprise apps. I first saw xmlhttprequest in a Cognos controller, I first saw drag+drop in a browser in another enterprise app.

the Outlook web interface was miles ahead of anything in the consumer space for years.

Indeed. We basically wrote our own version of jQuery, backbone.js and a whole functional toolkit with 150 functions and 30 client side controls and a validation framework about 5 years ago and it even worked on IE 5.5...

I thought that had more to do with the billions of dollars invested in IE-only web applications and the astronomical cost of upgrading, retraining and supporting thousands of people, not the fear that one version of Chrome will someday break CSS behavior.

No not at all. Most of the LOB applications you see these days work very well in most browsers. Ours works in Firefox, Chrome, IE, Safari perfectly and is entirely plugin free. I've not seen an ActiveX for about 5 years and that was a file upload control. All our fugly desktop integration is done with a broker application which runs on the user's machine and talks to local COM objects via web services. You see an occasional fugy J2EE page or a WebForms page but mostly, it's pretty spankingly good looking and works well. This is financial sector stuff as well which is the worst market for heel-dragging.

Corporations fear things breaking. Retraining is rarely an issue for a browser upgrade. However, if someone pushes out a crap Chrome update like this and an LOB application goes pop then heads roll. Chrome is entirely out of band from their normal operations and skill sets so it just doesn't even get considered. It also has dubious unpredictable support lifecycles and a rate of change which would scare anyone. To use a car analogy: they want a 3 year old Volvo, not a 6 month old Tesla.

I think being able to differentiate in the browser market is a great thing. Chrome can offer tools for enterprise use, but I seriously doubt that they are ever going to offer long term support for old versions. Meanwhile that's Microsoft's bread and butter, but that means that if you want a larger portion of experimental or recently finalized web features, you have to go somewhere besides IE.

What's bad is when you have to cater to old, broken IE behavior because you have to support that part of the market. We're seeing much less of that and more just "IE doesn't support new feature X". That does hold back some of the newest stuff, but not having typed arrays is not at all comparable to having to support IE6, for instance.

Personally, I would be ecstatic if we can maintain for as long as possible this nearly even split of marketshare over three (desktop) browsers.

What is your experience based on?

I've been working with some large enterprises in the past (50k+ employees), all of them only use IE and all of them are full with some crappy ActiveX software, some by HP, some homegrown, it's really full of that crap. :( Even software that would support multi-platform is crippled in a way that only Windows+IE works, because in the projects noone cares if some other browser or (god forbid) another OS is supported.

European finance, insurance, banking, news agencies, e-commerce and market research companies. We're talking large companies on the same scale.

In my experience those kind of companies are heavily involved with big players like MS, HP, etc. who all push their own proprietary crap. Bundle this with a "we don't allow employees to install other browers so why should we care/test/develop for other technologies? We can even assume every PC has ActiveX installed and ready, so hell yeah let's use that!"

That's funny, where I work (yes it's Enterprise scale) it is far more likely the tools work in Firefox than recent IE, Safari or Chrome.

Closer to the truth is that Enterprise's stick with whatever it was that their developers were using when they developed the tool. That just happened to be Netscape/Mozilla browsers when some of these tools were written where I work.

I think it's more correct to say they tail end what still works and is supported, which is why our baseline is IE7.

Enterprises love IE because it has Active Directory Group Policy hooks that allow you to customize and lock down the browser.

Chrome does, too: http://support.google.com/chromeos/a/bin/answer.py?hl=en&...

>Chrome 22 Breaks Everything

Followed by two things that are broken.

Don't forget it also apparently broke his server.

As I said earlier, I didn't mean that Chrome is completely, literally broken. I meant in the sense of a user having just updated their version of Chrome, going to a site, and not being able to do anything. For me and a few coworkers, this was exactly what happened to us when we started noticing these two issues last night. These two relatively minor CSS bugs have broken the functionality of a site we have been working on to the point where it is unusable.

I've been using chrome beta for a while (so i'm at 23 now and was at 22 a while) and never saw those problems. How many sites do you know that are broken, apart from your own project?

Funny thing is that, if you use the Chrome Developer tools on the first example "Floats don’t push block content down" and select in the source the <h1>, the tools highlight the position where the <h1> should be, and not the position it actually is. (a picture is better than a long explanation sometime: http://imgur.com/d5xnj )

Talk about an alarmist title of "breaks everything...". Appreciate the HN Mod changing it.

Oh, that's what happened? Apologies for the alarmist title, but depending on your site's CSS this can completely destroy its usability. I meant it in the sense of a user saying everything on a site is broken, not that everything in Chrome 22 is literally broken.

I agree. Add too much salt to the food and people will say that you've ruined it. Some people won't notice it because they are less sensitive or for other reasons but the food, for some, is ruined.

This happens a lot with the software development where one simple bug in your application makes the user say that "it doesn't work". We, as developers, tend to get mad when all our work is deemed unfunctional because of a simple error but we usually don't see that it is a "simple error" only from our perspective.

I don't. Anonymous title editing by mods (with no note that that's what happened) is probably the worst thing about HN.

Seems more facetious than alarmist.

I don't know if this is related, but I had an issue with flash yesterday which seems to correspond to the Chrome 22 release.

I was playing a game which had never had a serious issue before, and I noticed that the timing of things was way, way off. At first, I thought that my system was just lagging - I had a server VM running, Firefox (my main) always has a ridiculous number of tabs open, and I was playing the game in Chrome because I don't like logging into Facebook from my 'everyday' browser - but shutting down the most resource intensive applications did nothing for the game.

Eventually I checked the plugins page and noticed that Chrome's built-in Flash plugin had re-enabled itself - I disabled it a couple weeks ago due to some video streaming issues - and it was once again the default plugin for those applications, therefore overriding the (higher version) system wide install.

I'm really hoping I'm not going to have to babysit Flash every few weeks when Chrome updates, especially since there isn't always a visual cue that you're running a new version of Chrome.

I too saw plugin-container.exe grinding my disk to a halt yesterday. I'm considering going back to FF...

Your comment is confusing to me. plugin-container.exe is a Firefox process, not chrome.

I've also starting having some awful performance hitches involving Flash, which might be related. Sometimes if I watch a Youtube video, the whole browser window (not just the current tab) locks up for a few seconds. Just started happening a few days ago, on Chrome for Mac.

As I said in my last comment, Chrome has its own built-in Flash Player. Even if you have another player installed on your machine, the built-in one overrides it unless you specifically disable it.

If you have another Flash player installed, go to chrome://plugins and disable the one that was installed with Chrome. It's obvious by the 'Location' which one this is, at least on Windows. I don't have a Mac so I can't help you there.

It's possible that this is just a problem with Flash 11.3. When I was having the video issues a few weeks ago, I installed the newer 11.4 version. Chrome's built-in player still calls itself 11.3. I don't know if it's that Flash Player version that's having the issue, or Chrome's built-in version specifically. My only specific complaint was that Chrome 22 re-enabled the built-in player without my consent.

Me too. Ever since 22, Chrome has felt really unstable. Flash runs slowly, and if I have a bunch of tabs open, eventually pages start becoming completely white. If I pull a tab out to make it it's own window, Chrome crashes. I also can't seem to download anything anymore (Windows can't find the downloaded file).

Maybe it's just me, but I swear I didn't do anything weird to my system...

I ran into the z-index issue yesterday with an internal application that uses Twitter Bootstrap. It had been working perfectly for months, and then became unusable. After the new Chrome was pushed out, Bootstrap's modal dialogs were hidden behind the backdrop and therefore inaccessible.

It might have been an edge case related to the layout of this application, but ultimately I ended up having to patch bootstrap.js to fix it. I felt bad about editing bootstrap, but should anyone else need a temporary(?) fix, it came down to this code in bootstrap.js

this.$backdrop = $('<div class="modal-backdrop ' + animate + '" />')

- .appendTo(document.body)

+ .insertAfter(this.$element)

That change had been discussed even before the Chrome changes, here

https://github.com/twitter/bootstrap/pull/3825

https://github.com/twitter/bootstrap/issues/3217

So, is this a Chrome bug, or a new spec that's being followed?

If I understand correctly it's the latter. Make sure the z-index is set on the position:fixed element, not elements inside of it. See http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

While my server deals with the traffic, here are the important bits:

- Floats don’t push block content down (http://jsfiddle.net/cvalleskey/WD9pB/)

- Z-index breaking when element is a child of a fixed parent (http://jsfiddle.net/cvalleskey/9S3S8/)

Adding "clear: left;" to the h1's style seems to yield the expected result, perhaps the problem isn't with the floated items but instead with the blocks? Is there some new rule about the default clear behavior?

For the second issue, please read http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

interesting - that first one looks like it might be a bug. When you inspect it in the debugger, the h1 is entirely within the container, though the text is well outside.

Interesting bug that I was just running up against which might be related. I was trying to draw some text in a small box, but, while it worked in all other browsers, Chrome 22 was adding what appeared to be extra line height for no reason. The code looked roughly like:

    <div><span>TEST</span></div>
    
    div > span {
        line-height: 0;
        margin: 0;
        padding: 0;
        font-size: 12px;
        display: block;
        height: 12px;
    }

Yet the text was being drawn dramatically outside of the box!

Turns out that this only happens in Chrome 22 when it's inside a list with list-style-type: disc.

Chris, the position: fixed z-index issue is more widespread than you have there; I'm trying to come up with a case for reliable repro, but I just bumped into it a bit ago and had to redo some things to work around it. (full disclosure, I'm one of Chris's coworkers)

We have a fairly sophisticated HTML5 based Cardiology viewer that completely fell apart when Chrome 22 shipped. It dynamically creates video objects and layers canvases on top for measurements. Worked perfect through version 21. In 22, playback is jittery, the browser stops responding, then eventually freezes where you can't even close the browser window. Other tabs are affected as well even though the process is supposed to be isolated (i.e. new tabs go completely black when trying to play video).

The issue isn't fixed in Canary. We are doing our best to isolate it and provide a bug report that demonstrates the issue outside of the production environment.

Not directly related, but there was a comment in the original article that got me thinking:

>To test if your page is going to change, go to Chrome's about:flagsand turn on/off "fixed position elements create stacking contexts"

Wouldn't it be cool if webdevs could alter Chrome's rendering settings to simulate IE and Safari? This would be a huge productivity boon. I think it might be an interesting challenge for Chrome devs (to expose a reasonable set of levers) and webdevs (who would probably be responsible for coming up with collections of levers that work.

There is this plug-in which is similar: https://chrome.google.com/webstore/detail/hehijbfgiekmjfkfjp...

Something else that broke is if you have your home page set to multiple URLS. I don't mean what comes up on startup (set to whatever was open last) but rather what happens when you press the home button which can happen at any time.

Other browsers do allow multiple URLs to be specified, but Chrome doesn't. The workaround from time immemorial has been a chunk of Javascript that calls window.open on a bunch of URLs. In Chrome 22 only the first will open.

Is it me, or the settings button now looks like Android?

Yeah, Google decided the Wrench icon wasn't meaningless enough so they changed to something that means even less.

I presume it's for consistency with Android, since right now Chrome for Android still makes references to 'the wrench icon' in text.

Reminds me of this post: "What the hell does ≡ do, anyway?" http://ada.mbecker.cc/2012/06/14/goddamn-three-bars-icon/

I have a problem with videos in Chrome lately, too. I think since version 20 or 21. I think it's related to Flash. Whenever I play 2 videos at once in different tabs, it starts sounding bad, like the hardware can't handle the video or something, but I have a pretty powerful laptop, and I'm sure it's not the hardware's fault. It's very weird. It also didn't happen before.

Thanks for posting this. I just had to redo some CSS on my site because of it.

Even worse is that it also breaks the Garmin Communicator Plugin v 4.0.3. No more easy uploads to Strava from my Garmin 800 Edge. I don't know if this is Chrome or Garmin's fault, but the end result is that the end user doesn't have a working system.

Something else I personally noticed with Chrome 22 is that Doxygen's menu bar now appears to be totally wonky.

http://i.imgur.com/zHSYQ.png

It happens with every 'last' menu item. No idea where that came from, but it's the first time I've noticed a Chrome upgrade in a long while.

Could you please file a bug at http://new.crbug.com/ with a link to an example doxygen-generated page showing the issue? This doesn't look like something I'm familiar with.

I ran into a flexbox bug (which turns out to be by design):

http://code.google.com/p/chromium/issues/detail?id=152386 `display: -webkit-flex` disables `overflow: hidden`

Flexbox in general is still experimental; only Chrome 21+ supports the new spec.

Oh goodness, the floats thing isn't good. A lot of sites rely on that, including my own. D:

Every issue I've had recently with something breaking has been with Chrome - we see new issues cropping up almost weekly.

As much as I hate developing for IE, I know the issues at hand and know the solution to fix it will be stable - with Chrome, not so much.

I appreciate the documentation of this, because it provides a possible reason to some things suddenly breaking despite no relevant change in code.

In a complex code-base, there can be a lot to blame, but it's nice to have some plausible explanation.

I've also noticed issues with animations in Chrome 22. Everything is prefixed properly and works well in other Webkit browsers like Safari. Chrome doesn't even run the animation, it just flashes and shows up.

Anybody else have this issue?

I'm noticing problem with animating items, especially on sites the are using "parallax" motion.

Another big issue is a broken javascript profiler. I've been using this quite a bit to optimize code on a project I've been working on and noticed after I updated that you can no longer expand nodes. Pretty bummed.

I'm also having problems with the spell-checker. It just stopped working with the "English (United States)" language. When I switch it to Turkish, it works fine.

Did anyone else find that all their extensions disappeared?

As an extension developer - I'd definitely be interested in hearing if others are experiencing this and if so, how you resolved.

Since the update I've also encountered issues with box-reflect when used in combination with CSS3 transforms or box-shadows.

Nice catch. I'm seeing that too. The reflection appears out of position when you have a box-shadow on the element.

Ah, the wonders of web development portability across browser versions.

It sure beats the pains out of native development.

Not sure if related, but I am noticing a lot of things broken. One example is Brazilian Apple Store link for customizing an MacBook Pro Retina doesn't render in Chrome 22:

http://store.apple.com/br/configure/MC976BZ/A?

Whereas renders normally in Firefox and Chrome 21...

Can't believe there's no test case in their automated test suite which would've caught this before being released to tens of millions of users.

Not sure how they test, but they can build a library of typical HTML and CSS edge cases and generate renderings from both an older version and the new version, compare the renderings and flag any discrepancies for manual inspection.

The WebKit LayoutTests is huge and almost certainly covers this. Maybe a bad rebaselining of rendering results, or maybe this is the correct behavior and other WebKit ports will start exhibiting it...

I'm very glad this is HN front page, my site became actually blocked for all users because of a tour we had that used a floating overlay, but I still don't understand, is it a bug? or just following the specs? is there a concensus on this? if so, should we expect it to be fixed? or copied by other browsers?

So, Is this according to the spec or a bug?

it might be relegated to

"works as intended"

"feature" territory

akin to permission management issues in code.android http://code.google.com/p/android/issues/detail?id=6266

seems like the behavior ought have a toggle in

about:flags

(chrome is forked from chromium)

Reply on news.ycombinator.com