I cannot reproduce the problem because I don't have an account.

Are there any output in the devtools console?
Have you contacted with the site's developers? They may be able to provide useful information.

Hi,

You can access a sample "test drive" QBO company without an account I believe...

Try this:

https://qbo.intuit.com/redir/testdrive_ca

Cheers,
Jem 

Thank you for providing more feedback. Adding requester "yhirano@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks, now I can see the problem.

The devtools console says: "Uncaught ReferenceError: normal is not defined"
[1] seems a similar problem, and I guess [2] is related. nainar@, can you take a look?

1: https://bugs.pcbsd.org/issues/15085
2: https://productforums.google.com/forum/#!topic/chrome/_vprYpCS3DQ

Taking a look

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bd9df7c452f9a6aadc49214a4a09451fc726be92

commit bd9df7c452f9a6aadc49214a4a09451fc726be92
Author: nainar <nainar@chromium.org>
Date: Thu May 19 10:49:13 2016

Revert of Pseudo and non pseudo elements should return correct computed content value (patchset #14 id:260001 of https://codereview.chromium.org/1812763002/ )

Reason for revert:
BUG= 609848 

A lot of sites in production are depending on content returning an empty string.

Original issue's description:
> Pseudo and non pseudo elements should return correct computed content value
>
> This patch makes sure that content computes to "normal" for elements
> (not pseudo elements) and to "none" if the specified value of pseudo
> elements ::before and ::after is "normal."
>
> This patch makes us interoperable with all other browsers for the
> case of pseudo elements :before and ::after where the specified value
> is "normal".
>
> With regards to non psuedo elements we are now interoperable with IE
> and the spec and return "normal" for the computed content all all non
> psuedo elements.
> Other browsers are inconcistent on this behaviour:
> 1. Edge returns an empty string for non pseudo elements
> 2. FF returns none for non pseudo elements.
>
> The spec implemented is given here:
> https://drafts.csswg.org/css2/generate.html#content
>
> BUG= 597500 
>
> Committed: https://crrev.com/aaeefae6c3a945e7fcfef382c3a82002ffae0e19
> Cr-Commit-Position: refs/heads/master@{#383949}

TBR=alancutter@chromium.org,timloh@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 597500 

Review-Url: https://codereview.chromium.org/1977323002
Cr-Commit-Position: refs/heads/master@{#394729}

[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/css3/supports-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/css3/supports.html
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/css/content-property-quote-types.html
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/computed-style-listing-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/computed-style-without-renderer-listing-expected.txt
[delete] https://crrev.com/be6cc8b3ee9ec912533a2a57a8529f3a524ae0d9/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-content.html
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/css/nested-at-rules-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/css/nested-at-rules.html
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/dom/hover-after-dom-delete-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/fast/dom/hover-after-dom-delete.html
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-styles-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/LayoutTests/svg/css/getComputedStyle-listing-expected.txt
[modify] https://crrev.com/bd9df7c452f9a6aadc49214a4a09451fc726be92/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

This issue should be fixed in ToT - will merge into M51 as per: https://www.chromium.org/developers/the-zen-of-merge-requests

[Automated comment] Less than 2 weeks to go before stable on M51, manual review required.

Ping on the merge request

I see that the change wasn't reverted.  Chrome dev (52) has the fix.  Can this be fast tracked for a phase 4 post stable fix?

It affects our production apps:  www.arcgis.com, marketplace.arcgis.com, many others...

thanks.

Hi there, yes more reports of website broken due to this fix not being included in the (now released) Chrome 51. 

Could do with some feedback as to whether this will be patched in 51, or do we have to handle this as a "status quo" going forward?

bumping for review as well and adding to comment 11: this affects not just arcgis.com and associated properties, but any Esri customer who has deployed using our software; this is in the thousands of installations that will have to be individually patched, once we have patches ready for multiple versions of the software, if this change does not get reverted

please review and merge this fix as soon as possible

@philip can you help me get access to a repro with arcgis.com ?

Paul,

You can sign up for a free account to ArcGIS.com at
https://www.arcgis.com/home/createaccount.html or try a map without an
account at https://www.arcgis.com/home/webmap/viewer.html?useExisting=0.

Paul, 
Here's another repro case: go to http://www.arcgis.com/apps/webappviewer/index.html?id=28297f0be865402a83a9aac8d6ec1eac .  Try to pan the map or anything else. Nothing happens.  Works in all other browsers, incl Canary.

A few more sites affected: 
* http://www.somalia-gis.org/portal/home/webmap/viewer.html
* http://strimaps.si.edu/portal/home/webmap/viewer.html
* http://gispublic.co.lake.ca.us/portal/home/webmap/viewer.html
* https://gis.abilenetx.com/portal/home/gallery.html
* https://portal.geomil.ro/arcgis/home/gallery.html

Thanks bjorn! Appreciated. :)
I believe we're going to try to get this bugfix into Chrome stable, but here's the workaround story in the meantime:

-------------

The workaround is very straightforward and very safe. 

In the source (somewhere) you'll find the string `"x-parse"` (without the backticks, but with the quotes). Right afterwards, you'll find a conditional that evaluates if a variable ` != "none"`. The hotfix is to also make sure the variable is not the string "normal" either. 

In the original source, the diff looks like :

 	var parser = testElementStyle('x-parse', null, 'content');
  	var sheet = styleSheetElement && 
  		(styleSheetElement.sheet || styleSheetElement.styleSheet);
 -	if(parser && parser != 'none'){
 +	if(parser && parser != 'none' && parser != 'normal'){

In minified source it diff looks something like like

-       var a=d("x-parse",null,"content");a&&"none"!=a?h([eval(a)],c)
+       var a=d("x-parse",null,"content");a&&"none"!=aa && a!= "normal"?h([eval(a)],c)


This edit is safe and I'd recommend you try it out.

---------------

The core "bug" lives in the xstyle project, within dojo. It was reported [1] and fixed [2] in February 2015. A new release of xstyle with this fix was shipped [3] recently (on May 2nd) in xstyle v0.3.2. [4]

[1] https://github.com/kriszyp/xstyle/issues/44
[2] https://github.com/kriszyp/xstyle/commit/7acb8186ccee813802625ca600eda2e307f9542c
[3] https://github.com/kriszyp/xstyle/issues/53
[4] https://github.com/kriszyp/xstyle/releases/tag/v0.3.2

---------------

The change Chrome shipped is compliant with the W3C specifications, and apparently IE11 may have similar behavior. That said, I know this is a disruptive situation and I apologize for the broken state of your apps. 

Hi Paul,

Thanks for the info. We've merged the updated xstyle into our code and can confirm that the fix implemented in 0.3.2 looks to work OK. We're just going through QA with this at the moment and hope to get it out into production soon, before Chrome 51 gets widespread deployment.

We'll keep a close eye on the patch progress in the meantime.

Thanks,

Stuart H.

Hi Paul,

Thanks for the insight and action.  We have rolled the fix to most of our hosted online properties.  The problem we have is that our customers deploy our products on their own servers.  It will take us awhile to roll out the patches to them.  As we noted in the original ticket ( https://bugs.chromium.org/p/chromium/issues/detail?id=597500#c4 ), browsers are wildly inconsistent on this.  We would like more time to get the appropriate patches out to our customers before changing to match the spec.  

Thanks again.
Jeremy

Merge approved for M51 (branch 2704). +bhthompson, ChromeOS TPM, since this is labeled as a ChromeOS-only bug, please let me know if you have any concerns on getting this merged in. If not, nainar@, please merge this in ASAP if there are no outstanding issues, we are cutting another stable candidate for desktop early next week.

I'm pretty sure this affects all OS'es.

Almost definitely affects all OSs, can personally confirm on Windows and Mac.

As 51 upgrade is now pretty widespread with organizational auto-update policies, the service disruption caused by this bug that prevents access to arcgis.com products is also widespread. Any chance a hotfix will be available soon?

If sshruthi is happy with it, I am happy with it, merge approved from my perspective.

+ timloh@/alancutter@ as nainar@ is on Vacation during this week. could  anyone of you please merge this ASAP to M51 branch 2704 if there are no outstanding issues, we are cutting another stable candidate for desktop tomorrow (Tuesday). Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7597d46261e696554606f4ed3d0931147cc2d1ba

commit 7597d46261e696554606f4ed3d0931147cc2d1ba
Author: Alan Cutter <alancutter@chromium.org>
Date: Tue May 31 01:25:00 2016

Revert of Pseudo and non pseudo elements should return correct computed content value (patchset #14 id:260001 of https://codereview.chromium.org/1812763002/ )

Reason for revert:
BUG= 609848 

A lot of sites in production are depending on content returning an empty string.

Original issue's description:
> Pseudo and non pseudo elements should return correct computed content value
>
> This patch makes sure that content computes to "normal" for elements
> (not pseudo elements) and to "none" if the specified value of pseudo
> elements ::before and ::after is "normal."
>
> This patch makes us interoperable with all other browsers for the
> case of pseudo elements :before and ::after where the specified value
> is "normal".
>
> With regards to non psuedo elements we are now interoperable with IE
> and the spec and return "normal" for the computed content all all non
> psuedo elements.
> Other browsers are inconcistent on this behaviour:
> 1. Edge returns an empty string for non pseudo elements
> 2. FF returns none for non pseudo elements.
>
> The spec implemented is given here:
> https://drafts.csswg.org/css2/generate.html#content
>
> BUG= 597500 
>
> Committed: https://crrev.com/aaeefae6c3a945e7fcfef382c3a82002ffae0e19
> Cr-Commit-Position: refs/heads/master@{#383949}

TBR=alancutter@chromium.org,timloh@chromium.org
BUG= 597500 

Review-Url: https://codereview.chromium.org/1977323002
Cr-Commit-Position: refs/heads/master@{#394729}
(cherry picked from commit bd9df7c452f9a6aadc49214a4a09451fc726be92)

Review URL: https://codereview.chromium.org/2021163002 .

Cr-Commit-Position: refs/branch-heads/2704@{#681}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/css3/supports-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/css3/supports.html
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/css/content-property-quote-types.html
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/computed-style-listing-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/computed-style-without-renderer-listing-expected.txt
[delete] https://crrev.com/a24314402398d518cf198c2c9a3cace65f5050e3/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-content.html
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/css/nested-at-rules-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/css/nested-at-rules.html
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/dom/hover-after-dom-delete-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/fast/dom/hover-after-dom-delete.html
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/inspector/elements/elements-panel-styles-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/LayoutTests/svg/css/getComputedStyle-listing-expected.txt
[modify] https://crrev.com/7597d46261e696554606f4ed3d0931147cc2d1ba/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp

 Issue 615209  has been merged into this issue.

Verified issue not reproducible on the latest M51 using Shell browser.

Does this mean this will be fixed in M51 build that 'normal' users will automatically get? Or do they have to wait for the M52 build.
Thanks

This change was in the M51 stable candidate that we cut yesterday. It should be fixed in the next M51 release.

This patch is now pushing out to stable channel in version 51.0.2704.79 for Desktop (Win,Mac & Linux).

The issues with the arcgis.com services (and internal Portals) seems to be resolved with this update. @map...@gmail.com are you seeing the same result?

tpcol...@gmail.com arcgis.com and services were patched beginning late last week through the weekend and are no longer good test cases, however I can confirm that .79 resolves the problem for the installable software equivalents of arcgis.com (called Portal for ArcGIS)

Hi!

This issue should be fixed in M51 as per #35. Please comment here if this is not the case. 

Marking as Fixed in the meanwhile.

Thanks!

The regression is back on Chrome 67.0.3396.62 for any site that uses an older version of xstyle (prior to v0.3.2).

Hi futhark@, it appears that https://chromium.googlesource.com/chromium/src/+/11fb2ae26b6e84211adf8270eb4f0cf42b945fe8 breaks this bug again. PTAL, thanks!

#40: Do those sites just don't work in Edge / Firefox? That'd be really unfortunate :(.

I guess they work because FF computes to 'none' instead of 'normal'?

Also, I guess per https://drafts.csswg.org/css-content/#content-property that should return 'contents' now instead of 'none' / 'normal', but that may be a lost battle already given this bug...

Adding "RBS" per comment #40 & #41.

Which site/sites is affected this time around sindilevich?

It's been over a year since this issue was first bought up, it's somewhat surprising to me that some of these sites *still* depend on incorrect behavior.

Lots of sites that were affected by this in 2016 don't simply upgrade every other day or week.

Take the list of sites from #18:
http://www.somalia-gis.org/portal/home/webmap/viewer.html => no longer online
http://strimaps.si.edu/portal/home/webmap/viewer.html => no longer affected, upgraded to later release with fix
http://gispublic.co.lake.ca.us/portal/home/webmap/viewer.html => no longer affected, upgraded to later release with fix
https://gis.abilenetx.com/portal/home/gallery.html => still affected, on older release without fix
https://portal.geomil.ro/arcgis/home/gallery.html => no longer affected, upgraded to later release with fix

Three out of five have upgraded, one has gone offline, and the last one is still affected.

Thanks philip.
We've allowed two years for the sites in question to update, not days or weeks.

At this point I'm leaning towards not blocking on this as the impact appears to be quite limited.

Removing "RBS" based on comment #47.

I tend to agree with #48 in that that there was enough time to upgrade or locally patch xstyle's files to avoid breaking with the compliant browser behavior. Not that xstyle is used widely anymore, nor maintained properly.

My only concern arises about #42's: "Also, I guess per https://drafts.csswg.org/css-content/#content-property that should return 'contents' now instead of 'none' / 'normal'" comment.

We cannot return 'contents' since we don't support the 'contents' keyword which means it will not round-trip.

Thank you for your clarifications, #50. That means that sites that have already upgraded to xstyle v0.3.2 or patched their xstyle files otherwise, will work OK.

Maybe, this issue can be closed then.

 Issue 849634  has been merged into this issue.