Google Chrome bug?

[qtxasjo]

I get the same issue as Jess77, all text are reverted to Times New Roman in the Flare user interface (have tried both local host and MadCap URL solutions). The builds seem to be fine though in all browsers.

[subquark]

I have similar issues with Chrome 47. All our body text behaves like a link (in that it has a hover status turning it MadCap green!).

Also, our table headers have a hover behavior. o_O

I tried the fixes from this thread to no avail and will wait for a patch from Flare which is the best way to handle this.

Ahh, here Chrome was our saving grace from the madness of Internet Explorer (remember all the IE6 hacks?). =D

[snippygirl]

When is the patch coming out?

I tried method 2 (apply directly to hosted css without a build) but it didn't work. I will try method 1 now and see if a build resolves it.

But knowing when the patch will come will help me allocate my time. I don't want to spend hours trying to fix something that will be fixed "this week" so if we could know when it will be coming, MadCap, that would be great.

[Jess77]

@davelee - Well I was sure you must have been wrong because I would never ... except that I did.
That was the problem. I must have copied and pasted without those end characters and didn't notice. Then, I copied and pasted out of the file. The MadCap code works fine and did not cause any of the problems the localhost one did.

I feel like Michael Bolton - not the no-talent ass-clown who won grammies - the programmer in Office Space. He's supposed to code a program to debit percentages of pennies and winds up debiting $1000s instead. He yells, "I'm always doing that! Forgetting a period or a dash or something. Dammitt!"

Now, I know how funny that line really is .... and not.

[rob hollinger]

When is the patch coming out?

I tried method 2 (apply directly to hosted css without a build) but it didn't work. I will try method 1 now and see if a build resolves it.

But knowing when the patch will come will help me allocate my time. I don't want to spend hours trying to fix something that will be fixed "this week" so if we could know when it will be coming, MadCap, that would be great.

We are working on it and hoping to have it ready by the end of the week given we do not run into any snags.

To those making changes on their servers - Please be sure you include the entire line (If you miss the ending ");", it will mess up the entire stylesheet and what you see). If you are sure you did it right and are not seeing the styles applied, clear the browsers cache and test with a different browser. If all the styles are still messed up, something is incorrect and needs to be looked at.

Copy and paste the entire line:

Code: Select all

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

[Jess77]

Yes, copy and paste the entire line!

Also, make sure that the styles.css that you're adding it to is the one in the Resources folder and not for the skin. The developer did this wrong the first time and then so fast the second time that I didn't catch it even though I was standing behind him.

Also, when you're testing in the browser, press SHIFT + F5. This forces the browser to call the server again and not rely on the cache. If this doesn't work, then you definitely need to clear the cache. My boss showed me this tip and it's been a big help when I'm testing.

[ghillerson]

Thank you to Dave Lee and all in the forums for this fix.

Heavy pressure from above to get this fixed as of yesterday, and the @namespace in the stylesheet works fine. Whew!

- gary

[snippygirl]

Yes, thanks all, for posting here! I checked a bunch, and verified that our stylesheet had this:

Code: Select all

/*<meta />*/

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

Adding it to the live server CSS made no difference, so I ran a build with the updated CSS. The output had our same styling on the left nav TOC (yay!), but on the right, where the topic shows, it was wiped out of all styling (doh!). It showed up in black and white. So, i guess it did fix the hover issue ;P But, all the styling was gone. I reverted it and we are back to the same hover/font/bold/underline issue currently.

For our help, we have 17 projects that are nested inside our mother ship project. The CSS is the same file that is imported into each of the 17 projects. So when I applied the fix, the updated CSS went into each child project.
Maybe that's a unique setup from others here in this thread, and why the fix is not working for us? ¯\_(ツ)_/¯ But thought I'd mention it in case it's a clue if anyone has an idea of what I'm doing wrong. Cheers!

[snippygirl]

Oh a tip when testing in Chrome: right-click on the Chrome icon and choose "New incognito window" and it opens a window with no caching.

[mrmansfan]

We attempted changing the hover css lines to [class*=...] as MattyQ suggested, but that did not work for us. We still saw the hover over text change issue. Adding the namespace line did fix the problem for us. Thanks all for helping on this.

[Phlawm53]

------
I've read this thread and corresponding thread in the Users of Madcap Flare group on LinkedIn. I have a general understanding of the issue but do not have a clear idea what the implications are for Flare users in general.

Is it now the case that some special action must be taken to ensure compatibility with Google Chrome? Or is special action only necessary when using specific Flare features in conjunction with Chrome? Or...?

If Flare users who haven't stumbled upon this discussion or its LinkedIn group counterpart are likely to have problems delivering one or more Flare Targets to users of Google Chrome, might some sort of tech bulletin be in order?

Just asking -- I now know there's an issue but I'm not sure what that issue means to me. I can imagine many other Flare users bumping their figurative heads on this and being obliged to track down the cause and solution...(?)

Cheers & thanks for your help,
Riley
SFO

[shannong]

For what it's worth, we also have hover behavior on our XREFs and also our drop-down headers.

I just applied @robhollinger's suggested fix (pasting the following line as the very first line of our main project stylesheet):

Code: Select all

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

This single change makes all content render correctly again. Drop-down headers are showing hover styles correctly, as are xrefs and A elements too. We are not seeing the same thing as @MattyQ is reporting, and did not need to implement their specific fixes for :hover psuedo styles.

We are also not seeing the same thing that @Jess77 reported, which was needing to insert the @namespace declaration beneath the /*meta />*/ line.

For what it's worth, I did my testing in Chrome version 47.0.2526.80 m, which seems to be _very_ new (as of today or yesterday). Maybe Google fixed the issue in one of the early v47 builds that was causing @robhollinger's fix to not work for some of us?

[shannong]

Hmmm, however, it turns out that applying @robhollinger's suggested fix to our main project stylesheet is screwing up the internal stylesheet used by the XML editor. Fonts are all wrong, as if each topic does not "see" the stylesheet reference to the project stylesheet in the HEAD element (like so:)

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" MadCap:lastBlockDepth="16" MadCap:lastHeight="5261" MadCap:lastWidth="978">
    <head>
        <link href="../Resources/TableStyles/PatternedRows.css" rel="stylesheet" MadCap:stylesheetType="table" /><title></title>
        <link href="../Resources/Stylesheets/ZilliantTopNav.css" rel="stylesheet" type="text/css" />
    </head>
    <body>

ZilliantTopNav.css is our main project stylesheet and it is manually applied to every topic (due to the way the TopNav skin works: look at Step 8 of this Flare 11 Help topic).

[shannong]

Here is a slightly different issue for MadCap to consider in their fix for this problem:

I hope that the permanent fix will NOT use a callout to an .xsd file on the madcapsoftware.com site like this permanent fix does. You are planning for the fix to use internal project files only, correct?

If not, then you're going to create a problem for those of us who use rendered Flare projects as the Help content for Salesforce apps. Security review guidelines for Salesforce managed packages tend to flag anything you add to a Salesforce org that includes external callouts to the public Web like your simple "http://www.madcapsoftware.com/Schemas/MadCap.xsd" in @robhollinger's fix.

When we develop help for custom Apex pages in our Salesforce apps, we just render the entire set of Help pages in an HTML5 target that renders only the sidemenu proxy but not the topmenu proxy. Then enables users to see and jump to other closely related pages from the topic they originally land on. The entire HTML5 output folder is zipped up and included as a static resource in the Salesforce Managed package, and each Help URL within an Apex page points to a specific topic within the static resource. Finally, we use condition tags to "hide" all xrefs or A links that point outside of the topics that actually appear in the static resource.

This approach ensures that our Help pages _never_ contain a URL that tries to jump outside of the static resource itself. Your current workaround fix for this Chrome issue would introduce such a foreign URL link.

[MattyQ]

For what it's worth, I did my testing in Chrome version 47.0.2526.80 m, which seems to be _very_ new (as of today or yesterday). Maybe Google fixed the issue in one of the early v47 builds that was causing @robhollinger's fix to not work for some of us?

Just retested in the version of Chrome you're using, and the @namespace fix does now work for us. I was testing on 47.0.2526.73. (EDIT: I'm not seeing any issues with the XML editor, or with our internal stylesheet, as some seem to be experiencing.)

If not, then you're going to create a problem for those of us who use rendered Flare projects as the Help content for Salesforce apps. Security review guidelines for Salesforce managed packages tend to flag anything you add to a
Salesforce org that includes external callouts to the public Web like your simple "http://www.madcapsoftware.com/Schemas/MadCap.xsd" in @robhollinger's fix.

If that is the case, as a temporary solution, could you not just download the schema, include it as a file in the project, and set the url() reference to the local version of the schema? (Emphasis on temporary, as I agree, this should be handled in the implementation.)

[Jess77]

@phlawn - To give you an idea what we are all talking about, because of the namespace update in Google Chrome, the HTML5 output from Flare 11 looks like this when the you hover the mouse over the content:

Chrome47Issue.png

It's using the hover styles that have "MadCap |" at the beginning for all the text in the body area. That's a bit of an oversimplification, but it's basically it.

My hover styles underline a hyperlink, which itself is already bolded. The effect, therefore, is to bold and underline all text. Since the mouse is on the H2 specifically, it's also applying the hyperlink style.

If you use web output, users will see this problem is they use the Chrome browser. You need to change your projects if your users ever open your output in Chrome.

Does that help?

[shannong]

If not, then you're going to create a problem for those of us who use rendered Flare projects as the Help content for Salesforce apps. Security review guidelines for Salesforce managed packages tend to flag anything you add to a
Salesforce org that includes external callouts to the public Web like your simple "http://www.madcapsoftware.com/Schemas/MadCap.xsd" in @robhollinger's fix.

If that is the case, as a temporary solution, could you not just download the schema, include it as a file in the project, and set the url() reference to the local version of the schema? (Emphasis on temporary, as I agree, this should be handled in the implementation.)

I thought of that but I just get a 404 error when trying to download it. Beside, the contents of that schema might be a moving target as MadCap works to fix the issue in the product itself? For now, we're just fixing all of our online doc but not the static resources used for our embedded Salesforce Help.

[feitelberg]

While the fix you describe works well, it seems to break preview.

Any fix for that?

[subquark]

hi feitelberg, MadCap is working on a patch as indicated in a previous comment. That update may be ready this week.

[benjimenez]

• 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

Worked for me. Thank you! I'm using Top Nav and added the @namespace to two stylesheets.

[rob hollinger]

Hmmm, however, it turns out that applying @robhollinger's suggested fix to our main project stylesheet is screwing up the internal stylesheet used by the XML editor. Fonts are all wrong, as if each topic does not "see" the stylesheet reference to the project stylesheet in the HEAD element (like so:)

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" MadCap:lastBlockDepth="16" MadCap:lastHeight="5261" MadCap:lastWidth="978">
    <head>
        <link href="../Resources/TableStyles/PatternedRows.css" rel="stylesheet" MadCap:stylesheetType="table" /><title></title>
        <link href="../Resources/Stylesheets/ZilliantTopNav.css" rel="stylesheet" type="text/css" />
    </head>
    <body>

ZilliantTopNav.css is our main project stylesheet and it is manually applied to every topic (due to the way the TopNav skin works: look at Step 8 of this Flare 11 Help topic).

This will be fixed in the update to Flare 11. The CSS parser is skipping the first style (generally the body style where the font family is set). If you place an empty style above that first style, it will then render correctly in Flare.
Again, this will be fixed in the update.

[snippygirl]

Ermahgerd I just fixed it for our tri-pane help, and it was a silly interpretation on my part.

What did not work: putting the @namespace fix in our master CSS only
What did work: putting the @namespace fix in EVERY CSS. So, put it in master css + any sub-project css. That is, put it in any css you have.

before figuring that out, I did upgrade to the latest Chrome as mentioned above, but that upgrade didn't fix it for us. jfyi

[snippygirl]

Oh and to clarify, the fix wipes out styling when in place during a build. it needed to be put in the file post-build.

[MattyQ]

Oh and to clarify, the fix wipes out styling when in place during a build. it needed to be put in the file post-build.

I'm not seeing any issues in the build process on our end -- is it maybe a syntax issue? The CSS parser in Flare is pretty fragile.


Just as a thought, for those running into an issue with Preview and such -- have you tried switching your default browser to Chrome? We've had some issues with this stuff in the past that was solved by switching the user's default browser. This is totally a shoot-from-the-hip idea, but it may be why I'm not seeing some of these problems.

[subquark]

w00t! the update fixes this issue - thank you MadCap! =D