Google Chrome bug?

[jackdeland]

Anyone else have a prob where passing the cursor over HTML 5 Help displayed in Chrome causes all the text to go bold? I'm testing the latest: Version 47.0.2526.73 m

Tried this with a tripane and a flyout menu version of the same files.

??

[jackdeland]

Support confirms this is a Chrome bug, and Google is working on it.

[Robotman]

Same is happening with our tri-pane HTML5 output. Thanks for confirming.

[ecjoe]

A quick test indicates that this issue was introduced with version 47. Everything was working fine prior to the update from 46 to 47.

@jackdeland: Thanks for the update.

[snippygirl]

This has hit us as well. Currently looking at css updates to resolve it, but so far no luck for us with our tri-pane HTML5 help.

A co-worker who outputs frameless got it fixed by adding the following line to the top of the CSS file (before the @media rule):

@namespace MadCap url(http://www.companyname>.com);

However, when we tried it with our tri-pane help, the build rendered without any formatting at all. As if there were no CSS. So we're still searching for a fix.

Has anyone opened a ticket with MadCap yet?

[snippygirl]

Okay, I've opened up a ticket with MadCap. Will update if we figure something out.

[snippygirl]

Watching this too: https://productforums.google.com/forum/ ... Csort:date

[djohnson]

My tri-pane project in Flare 11.1 has only 1 CSS file; after the @import rule I added

Code: Select all

@namespace MadCap "localhost";

and lo and behold, this worked, even from a live web server!

I knew nothing about @namespace until customers and coworkers started reporting this issue and it has been a whirlwind trying to get somewhere. This post, with the link to the Google bug posting, led me to this solution that seems to work.

In my TopNav sites, this decolorizes the SideMenu when I view it on a local web server, but all other hovers work fine, and everything works when hosted on a "live" web server.

Any suggestions, and anywhere else I should keep a look-out in my help for bad behavior?

= = (Added later) = =

Although this was not very nice of Google, I don't expect they will "fix" it, as with the debacle with cross-frame scripting from a few years ago. Because my older pre-Flare 11 help systems appear to work fine in Chrome 47, it seems like an issue that could be addressed with a Flare update.

[snippygirl]

Thanks for the info, djohnson! That didn't fix our issue, but maybe if we keep working at namespace variations, we'll stumble on a fix that works for us.

Haven't heard a reply yet from MadCap from the bug i opened yesterday. Will update here if I hear any ideas from them.

[snippygirl]

Heard back from MadCap:

"With the recent Chrome 47 update, Google changed it's procedures to now accept "namespaces" for the CSS which causes this issue. Since we do not know of when or if Chrome is going to revert back, MadCap is developing an update that will add a "namespace" to the CSS. This update should be available soon. "

[sarrants]

Anyone else have a prob where passing the cursor over HTML 5 Help displayed in Chrome causes all the text to go bold? I'm testing the latest: Version 47.0.2526.73 m ?

I am using Chrome 47.0.2526.73 m and I'm not seeing this. Is this a random thing?

[djohnson]

The latest version of Chrome added support for the @namespace rule in CSS; this implementation is causing the problems we've been seeing with help systems.

The "hover" issue apparently only affects help systems built with recent (maybe only the latest?) versions of Flare 11.

I have seen it on some tri-pane help but not on others, so it probably has to do with how the "hover" selectors are defined in CSS.

I am seeing underlining on my help systems; I presume you have something like

Code: Select all

a:hover { bold; }

defined, which is why you are seeing bold.

[ChrisBradley]

My tri-pane project in Flare 11.1 has only 1 CSS file; after the @import rule I added

Code: Select all

@namespace MadCap "localhost";

djohnson,
I applied this setting at the top of my CSS sheet and it fixed the hover over issue in our webhelp. Thanks for the advice!
I'm not seeing any issue with the navigation like you have reported.

[BrienneOfTech]

djohnson,

I also applied your fix (only just came upon this problem and was freaking out!).

It worked. Brilliant. Thanks so much!!

[NorthEast]

Thanks for posting this.
Just noticed that the CSS in our sites is broken for Chrome.

However, I tried the fix using @namespace MadCap "localhost"; , and although it fixed our style issues, it also breaks master page references in Flare's build process.
We set master pages using html classes and the mc-master-page property; but this doesn't work if you use that namespace fix.
For example, setting a master page like the example below wouldn't work, and is ignored in the build process:

Code: Select all

html.test { mc-master-page: url('../MasterPages/test.flmsp'); }

[MattyQ]

If it's helpful, I created a workaround for this issue for our organization, since we've also encountered it. In our case, the issue was that the MadCap|dropDownHotSpot:hover style was getting applied to all elements in the topic. I worked around this by converting MadCap|dropDownHotSpot:hover to [class*=dropDownHotspot]. "Hotspot" is critical -- it looks like the dropdown hotspots use a different case in the class name (dropDownHotspot, versus dropDownHotSpot, which is the class in every other reference).

I imagine if you're running into similar issues with MadCap|<...>:hover issues, you could work around it in a similar method, by switching them to the [class*=<...>]:hover selector.

For visual reference, the original CSS:

originalCss.png

And the CSS as I've modified it:

updatedCss.png

[Jess77]

Has anyone here found a solution that can fix it on the web?

Is there some code a developer can enter where these files are already deployed that will fix this temporarily?

[ecjoe]

@Jess77: djohnson's solution of adding the @namespace to the top of each CSS file seems to work for my local copy and the version hosted on our servers. Although I haven't been able to update the web version of our HTML5 help, I was able to test the fix by manually adding that line to the corresponding CSS files using Chrome's Developer Tools.

@Dave Lee: For what it is worth, my project also contains a style that sets the mc-master-page property. Adding the namespace line didn't break this reference when I built it on my machine. I haven't tried posting the output to our web servers yet.

[MattyQ]

Has anyone here found a solution that can fix it on the web?

Is there some code a developer can enter where these files are already deployed that will fix this temporarily?

The fix I detail above does work on the web, and I've already deployed it to all the project output on our server. It's functioning fine and as expected now. I've created a patching utility that automates the change in the CSS files, on our end.

[rob hollinger]

As a temporary fix and for those who would rather fix already published content use step 1 or 2 below.
MadCap will be issuing a patch/update for this over the next few days that will update Flare 11 and resolve this issue.

The problem is the "MadCap" named styles in the stylesheet. Chrome is now enforcing namespaces and because it does not know what "MadCap" is, those classes get applied to all body content.

There are two ways to patch this issue (1 requires the project be re-published, 2 requires updating the stylesheets in the output or on the server):

• Add the following namespace to the top of the master CSS file in the Flare project.
  • Open the project master stylesheet file in a text editor.
  • Add the following line to the top of the stylesheet (Copy paste the entire line below):
    @namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd);
  • Build and publish the project
  • Verify the results
• Browse to where the Output is stored
  • Open the project master stylesheet in a text editor
  • Add the following line to the top of the stylesheet (Copy paste the entire line below):
    @namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd);
  • Save and verify

Additional information:
The issue stems from the new feature in Chrome 47 to support CSS Namespace rules. Namespace rules were previously ignored, and now appear to match anything. For example:

google|foo:hover {
color: red;
}

Previously matched nothing, as namespaced CSS was not supported (that CSS should match a tag named <google:foo> being hovered).
Now that same CSS is matching ANY element on the page, UNLESS the namespace is defined above in the CSS file as such:

@namespace google url(http://www.google.com/example/css);

For details on the Chrome feature implementation see:
https://codereview.chromium.org/1321943002
https://code.google.com/p/chromium/issu ... ?id=389549

For details on CSS namespaces see:
http://reference.sitepoint.com/css/at-namespace

[MattyQ]

The issue stems from the new feature in Chrome 47 to support CSS Namespace rules. Namespace rules were previously ignored, and now appear to match anything.

Hi, Rob, sorry to trouble you. -- This doesn't appear to be the case in our output. The MadCap namespace styles are being applied appropriately in Chrome 47. The issue we've encountered is using the :hover selector with the dropDownHotSpot element. Is there a reason why the rest of the MadCap elements are fine?

As an example, my stylesheet currently contains the following:

Code: Select all

MadCap|dropDown
{
	mc-closed-image: url('../Images/DDExpand.png');
	mc-image-position: right;
	mc-image-spacing: 20px;
	mc-open-image: url('../Images/DDCollapse.png');
	margin-top: 1em;
}

MadCap|dropDownHotSpot
{
	color: #666666;
	font-size: 14pt;
	font-weight: bolder;
	transition: color 0.25s;
}

MadCap|dropDownHotSpot:hover
{
	color: #007aff;
	transition: color 0.15s;
}

MadCap|glossaryTerm
{
	color: inherit;
	font-family: 'Open Sans Semibold', Arial;
	font-weight: normal;
	mc-closed-image: url('../Images/information-alt.png');
	mc-open-image: url('../Images/information-alt.png');
	background-position: right center;
	opacity: 1;
	transition: color 0.25s;
}

MadCap|relatedTopics
{
	mc-help-control-display: list;
	mc-image: none;
	mc-image-alt-text: ;
	mc-image-position: none;
	mc-image-spacing: 0px;
	mc-label: "Related Information";
	mc-use-custom-sort-order: true;
	margin-top: 1em;
}

MadCap|relatedTopics.WhatsNext
{
	mc-label: "What's Next?";
}

MadCap|relatedTopics.Procedures
{
	mc-label: "Procedures";
}

All text in the topic turns blue, as expected, when you hover. The rest of the MadCap styles are not applied to all elements (you can confirm this by viewing the Computed styles for an element in Devtools -- only the :hover styling is applied).

However, if I add the namespace reference to the top of the stylesheet, the transition and the color change in the served content are lost. The dropdown hot spot no longer reflects any :hover styling. The rest of the page is fine, but you cannot view any styles applied with :hover, :active, etc.

Only if I replace MadCap|dropDownHotSpot:hover with [class*=dropDownHotspot] do I see the expected output.

[rob hollinger]

It's those Pseudo classes that are not handled by the browser correctly.

Other examples would be:
MadCap|popup:hover
MadCap|xref:hover

If you were to set the xref hover class, that would take over as soon as you corrected the dropdownhotspot styles.

[MattyQ]

It's those Pseudo classes that are not handled by the browser correctly.

Other examples would be:
MadCap|popup:hover
MadCap|xref:hover

If you were to set the xref hover class, that would take over as soon as you corrected the dropdownhotspot styles.

Gotcha! Thanks very much for the patience. The namespace reference doesn't rectify our issues, unfortunately, so we're stuck with the other workaround for now.

EDIT: Tested it singularly with the xref hover class in a new project, added only from the Flare Stylesheet Editor, and we see the same issue, with @namespace only causing the :hover style not to be displayed at all.

Both of the following ways, for what it's worth:

Code: Select all

@namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd);

/*<meta />*/

Code: Select all

/*<meta />*/

@namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd);

Code: Select all

MadCap|expandingHead
{
	font-style: italic;
	font-weight: normal;
	cursor: hand;
	text-decoration: none;
	color: #006600;
}

MadCap|expandingBody
{
	color: #777777;
	font-style: italic;
}

MadCap|dropDownHotspot
{
	cursor: hand;
	font-style: italic;
	text-decoration: none;
	color: #006600;
}

MadCap|xref:hover
{
	background-color: #ff0000;
}

[Jess77]

EDIT - Our lack of ability to update the server has to do with the developer updating the wrong "styles.css". He was accidentally updating the skin styles.css file. I did not know they had the same name until now.

@ecjoe - We were able to fix it by updating the local files. When I posted the output to my locally hosted website (via IIS and wwwwroot), it works. However, we could not fix the files on the server. We had to republish to the live site.

@robhollinger - The solution you posted did not work for us. The solution that did work was

Code: Select all

/*<meta />*/
@namespace MadCap "localhost";
body

"@namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd" in the same location 1) did not fix the problem and 2) removed the stylesheet formatting. All text reverted to Times New Roman.
I'm assuming that we would remove whatever workaround worked after installing the patch.

@djohnson - The @namespace MadCap "localhost"; solution did work but it caused the following
-Very odd formatting in the source files - Some lines have no formatting (i.e., Times New Roman) and some do (the font in the style). It's bizarre to work in, but the output does looks as it should.
-Some files were no longer valid as XHTML. I put them through the wizard, which seems to have added a lot of JavaScript.

[NorthEast]

"@namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd" in the same location 1) did not fix the problem and 2) removed the stylesheet formatting. All text reverted to Times New Roman.
I'm assuming that we would remove whatever workaround worked after installing the patch.

If that is exactly what you included, then it wouldn't work - it's missing ); from the end

@namespace MadCap url(http://www.madcapsoftware.com/Schemas/MadCap.xsd);

MadCap's solution appears to work for us (so far), I haven't seen the same issue that I had when setting it to localhost.