Open Bug 1569291 Opened 5 years ago Updated 2 years ago

Help Files created through MadCap Flare do not work

Categories

(Core :: DOM: Security, defect, P3)

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- fix-optional

People

(Reporter: JoseLAguilarG, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

firefoxnotworking.PNG
19.13 KB, image/png
Details
Attached image firefoxnotworking.PNG —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I opened up previously working help documentation created with MadCap Flare with Firefox and the page does not load. It loads with all other browsers except firefox.

Actual results:

The page did not load

Expected results:

The page should have loaded

Hi Jose,

Sorry for the delay in answering you. Could you give me an URL to try and reproduce this?

Thanks in advance, Flor.

Flags: needinfo?(JoseLAguilarG)

Hi Jose,

I'm marking this as Resolved-Incomplete due to lack of response. If the issue is still reproducible with the latest Firefox version, feel free to reopen the bug with more information.

Best regards, Flor.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE

Hello, I apologize I miss this email and wanted to follow up.

We do not host this site documentation online but you can download our software and install it.

https://www.tainstruments.com/support/software-downloads-support/downloads/

Our TRIOS analysis software can be downloaded through here.

When running the installer, the last page is Shortcuts. Be sure to check Online Help. This creates a desktop shortcut to our help files.

click on the shortcut and then click on any of the instruments View Help Button.

Observe, the web page opens up fine but nothing is display. If you try to reproduce this behavior on chrome or Microsoft edge, it does not happen.
The software we use to build our help documentation is madcapsoftware

Flags: needinfo?(JoseLAguilarG)

Hi Jose,

Ok, with the str it was "easy" to reproduce this bug. Thanks for the details. I was able to reproduce the bug on Windows 10 on the following versions:

Release 69.0 (64-bit), Nightly 71.0a1 (2019-10-08) (64-bit) and Beta 70.0b13 (64-bit).

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Status: RESOLVED → REOPENED
status-firefox69: --- → affected
status-firefox70: --- → affected
status-firefox71: --- → affected
Component: Untriaged → Layout: Images, Video, and HTML Frames
Ever confirmed: true
Product: Firefox → Core
Resolution: INCOMPLETE → ---
Version: 68 Branch → Trunk
Status: REOPENED → NEW

Hi Florencia, given you could reproduce, is there any chance you could run mozregression to see when it broke? According to comment 0 it worked in the past.

It isn't necessarily a layout issue (I'd say it most likely isn't).

Thanks!

Flags: needinfo?(fdiciocco)

Hi Emilio,

Sure, here it is: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4d37f42cecafac5c14d3dbc20a9204643b5cc3ea&tochange=d0dda220d0d270babd2026b7f88ebd368fef4fa1. As the reporter said, this was working till the 6 of July.

Regards, Flor.

Flags: needinfo?(fdiciocco)
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regressionwindow-wanted

Thanks!

Seems like fallout from bug 1558299 then.

Reporter / Florencia, mind confirming that changing privacy.file_unique_origin to false fixes the issue?

Component: Layout: Images, Video, and HTML Frames → DOM: Security
Flags: needinfo?(amarchesini)
Regressed by: CVE-2019-11730

Yes, that fixed the issue.

Can you give me an example of that page? Does it use HTML frameset or something similar?

Flags: needinfo?(amarchesini) → needinfo?(JoseLAguilarG)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" lang="en-US" xml:lang="en-US" MadCap:TargetType="WebHelp" MadCap:PathToHelpSystem="./" MadCap:RuntimeFileType="Default" MadCap:HelpSystemFileName="TRIOS_Help_DHR-AR.xml" MadCap:PathToSkinFolder="Data/SkinTRIOS_Blue/" MadCap:InPreviewMode="False">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>WebHelp</title>
<script type="text/javascript">
/* <![CDATA[ /
if ( window.name != "_MCWebHelpCSH" ) // window.name might already be set to "_MCWebHelpCSH" from a CSH call
{
window.name = "MCWebHelp";
}
/ ]]> /
</script>
<script id="MCGlobals" type="text/javascript">/<![CDATA[/var gSubsystemFile = "TRIOS_Help_DHR-AR.xml";
var gSkinFolder = "Data/SkinTRIOS_Blue/";
var gSkinTemplateFolder = "Skin/";
var gDefaultStartTopic = "Content/Welcome Topics/Welcome to TRIOS_DHR-AR.htm";
/]]>*/</script>
<script type="text/javascript" src="Content/SkinSupport/MadCapAll.js">
</script>
</head>
<frameset rows="28, *" border="1" framespacing="0">
<frame name="mctoolbar" title="Toolbar" src="Skin/Toolbar.htm" frameborder="0" scrolling="no" longdesc="Content/SkinSupport/mctoolbar_longdesc.htm" noresize="noresize" />
<frameset border="4" framespacing="2" cols="350, *">
<frame name="navigation" title="Navigation" src="Skin/Navigation.htm" frameborder="0" scrolling="no" onresize="frames['navigation'].SetIFrameHeight();" longdesc="Content/SkinSupport/navigation_longdesc.htm" />
<frame name="body" title="Topic" frameborder="1" src="Skin/Blank.htm" longdesc="Content/SkinSupport/body_longdesc.htm" />
</frameset>
</frameset>
</html>

Looks like it uses HTML frameset

Flags: needinfo?(JoseLAguilarG)

if you want to view it you would have to download our software as we do not host the help documentation online.

https://www.tainstruments.com/support/software-downloads-support/downloads/
Our TRIOS analysis software can be downloaded through here.
When running the installer, the last page is Shortcuts. Be sure to check Online Help. This creates a desktop shortcut to our help files.
click on the shortcut and then click on any of the instruments View Help Button.
Observe, the web page opens up fine but nothing is display. If you try to reproduce this behavior on chrome or Microsoft edge, it does not happen.

Summary: Help Files craeted through MadCap Flare do not work → Help Files created through MadCap Flare do not work

Heads up on the response :baku :).

Flags: needinfo?(amarchesini)

I installed the application and I confirm that firefox has a different behavior than chrome when rendering the documentation pages.
I'll work on this bug this week.

Flags: needinfo?(amarchesini)
Assignee: nobody → amarchesini
Priority: -- → P2
Whiteboard: [domsecurity-active]

It seems that MadCap supports only chrome when documentation is loaded from file URLs. In MadCapAll.js, there is this check:
function FMCIsChrome() {return Boolean(window.chrome); }. On Chrome, this returns true, and MadCap creates a wrapper to support file URL same-origin restrictions. On firefox, this function returns false and the loading breaks.

We should contact MadCap to update their code.

Andrew, do you know how to proceed in this case? Do we have someone in mozilla who can contact MadCap?

Flags: needinfo?(overholt)

Jose, would you be able to contact MadCap, since you're presumably their customer? They are literally running different (broken) code in Firefox compared to what they run in Chrome...

Flags: needinfo?(JoseLAguilarG)

If Jose is unable to do so successfully, we can ask Adam Stevenson to help out.

Flags: needinfo?(overholt)

Sure, just let me know.

There is a bug form here:
https://www.madcapsoftware.com/feedback/bugs/

We have shipped our last beta for 71 and this seems to be a webcompat issue on which we have no control for the Firefox release, so this is wontfix for 71.

status-firefox71: affected → wontfix
status-firefox72: --- → affected

Is this still broken? If not, I'll report it through their form. But if it's fixed I'd like to close the bug. Thanks!

status-firefox72: affected → wontfix
status-firefox73: --- → fix-optional

Redirect a needinfo that is pending on an inactive user to the triage owner.
:ckerschb, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(JoseLAguilarG) → needinfo?(ckerschb)

Taking :baku off and putting in the backlog...

Assignee: amarchesini → nobody
Flags: needinfo?(ckerschb)
Priority: P2 → P3
Whiteboard: [domsecurity-active] → [domsecurity-backlog1]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: