User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: Since updating to Firefox 15, a page inside my Cisco ACS appliance does not render: Access Policies > Access Services > Default Network Access > Authorization. The Cisco appliance is not public-facing, so I am happy to do a screen-sharing session with a Mozilla engineer if it would help troubleshoot. Actual results: The page has historically taken 15-20 seconds to fully load its contents, and the page now renders as if Firefox 15 got sick of waiting and just displayed what content it had. Is this a problem with rendering the page or perhaps did the value of a timer get changed in Firefox 15? Expected results: It should show a table filled with content.

Can you try with a new profile, please. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Indeed, a limited access to the webpage will be better to test a possible regression.

Same behavior with a new profile

There is nothing that we can do without a testcase. Which engineer have to look at an issue depends on the area of that issue. We have different engineers for example for the Javascript Engine, DOM, Networking:http, Networking:Cache, SSL, CSS,..... Loic and I'm a bug triagers that try to identify the area and without testcase or other information this is not possible.

I am happy to provide a testcase, can you either let me know what I need to do on my side or let me know who to work with in order to coordinate a remote screen session? Can I do some sort of capture or debug and attach the zip file to this bug report? Just let me know what you need from me and I'll do it

If it helps, I've also submitted this problem to the general Firefox support forum and someone provided an HTML-based fix in the comments: https://support.mozilla.org/en-US/questions/935768?s=&r=0&as=s As a followup comment indicates, this fix does not help if working with appliances since access to the filesystem is prohibited, and cracking into it will void support warranties. However, that comment may provide some insight as to what changed in Firefox 15.0 that caused this problem to surface

Is it possible you create a guest account with limited rights on your Cisco ACS server that could allows to test the issue? (the login can be emailed to a dev e.g.) Or do you know an online Cisco demo maybe?

Or if it's only a rendering issue, can you save locally the webpage and attach it to the bug?

The device is located on an internal network so creating a temp/guest account wouldn't do much good. And I can't give unsupervised VPN access either for security reasons. As I suggested, I think a screen sharing session would be most effective if we're looking to accomplish a live demo. But sure, let me see if I can save the page locally and attach it. How do I attach it?

After looking twice and missing it, I finally spotted the attachment link. I will do it as soon as I can. Thanks for your responses.

I've saved the page locally, but when opening it up from my desktop, it gives an error because it's looking for a file that ends in .do and can't find it. Not sure how to get around that. Following the spirit of your suggestion, though, I pulled up the source of the page that isn't rendering properly and sure enough, in the source I can see all of the information that SHOULD be displayed. I'm going to attach three screenshots to this bug: - One of the page as rendered in IE - One of the page as rendered in Firefox 15.0.1 - One of the source as seen in Firefox 15.0.1. I've done a search for a string of text visible in the IE screenshot, which is highlighted. As you can see, the text string exists in the source that Firefox is trying to render Let me know what else I can do to help

(In reply to bugzilla.mozilla.org from comment #10) > I've saved the page locally, but when opening it up from my desktop, it > gives an error because it's looking for a file that ends in .do and can't > find it. Not sure how to get around that. Even if all the dependencies are not saved, is the page bad rendered locally too? If that's the case, zip the webpage (.html and its folder) and attache the archive, please. Maybe there is surely a possibility to create a reduced testcase.

I'm afraid I don't understand exactly what you're asking, but I've tried to save the page in two different ways and can't get it to do a "bad local render" I will attach each attempt because you will probably be able to do something I'm not thinking of

Ok, thanks, I'm able to reproduce the rendering bug in FF15 vs an old version (FF8 here). I'll try to find a regression range.

Thanks Loic. In comment 5 I referred to a suggestion to change instances of "->" into "-->" in the source. Would you feel like giving that a shot to see if it does indeed render properly following that modification?

(In reply to bugzilla.mozilla.org from comment #19) > Thanks Loic. In comment 5 I referred to a suggestion to change instances of > "->" into "-->" in the source. > > Would you feel like giving that a shot to see if it does indeed render > properly following that modification? I didn't find the file index.jsp so I renamed PolicyInputAction.do.htm into PolicyInputAction.do and it worked. Mozregression range: m-c good=2012-06-01 bad=2012-06-02 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73783bf75c4c&tochange=5199196b65ec m-i good=2012-06-01 bad=2012-06-02 http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=50c9995aa7d0&tochange=9abc60f44fd5 Maybe a reduced testcase will be better.

Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/cb648ec7d7f2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601025002 Bad: http://hg.mozilla.org/mozilla-central/rev/7bf0125b26b5 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120601035703 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb648ec7d7f2&tochange=7bf0125b26b5 Triggered by: 7bf0125b26b5 Olli Pettay — Bug 744830 - Implement fast serializer for innerHTML/outerHTML, p=jdm+smaug, r=hsivonen

Thanks for narrowing down the reg range.

Error console said as follows: Error: not well-formed Source file: file:///D:/ACS/GettingStartedInputAction.do Line: 1971, Column: 20 Source code: <operator name="<" value="LESS_THAN"></operator> So, I think this is related to Bug 788444 .

(In reply to Alice0775 White from comment #23) > Error console said as follows: > > Error: not well-formed > Source file: file:///D:/ACS/GettingStartedInputAction.do > Line: 1971, Column: 20 > Source code: > <operator name="<" value="LESS_THAN"></operator> > > > So, I think this is related to Bug 788444 . I take it they run different code in IE?

cues_taglib.js do browser sniffing

Tracking for FF17 and 18 to see if we need to do outreach or take an in-product fix in the future, but it's too late in FF16 to take a for a small affected population.

Also, we're doing now what the spec says.

(In reply to Olli Pettay [:smaug] from comment #27) > Also, we're doing now what the spec says. Also, what IE does, so we’re OK when the innerHTML code given to us is the same as the code given to IE. However, it wouldn’t be unthinkable to make both the spec and our impl escape < and > in attribute values.

If we did that, would our behavior be different than anyone else?

(In reply to Olli Pettay [:smaug] from comment #29) > If we did that, would our behavior be different than anyone else? WebKit escapes < and >. IE and Opera don’t. (IE since forever, in the case of Opera, I don’t know since when.) That is, right now, we are a WebKit patch away from everyone doing the same thing (the thing that breaks this Cisco appliance’s UI).

(In reply to Henri Sivonen (:hsivonen) from comment #30) > in the case > of Opera, I don’t know since when.) zcorpan says since http://html5.org/tools/web-apps-tracker?from=2362&to=2363 So it seems some code at Expedia wants the opposite behavior compared to this Cisco thing...

WebKit has a special case for the Expedia problem: If the attribute reflects as a URL attribute and the URL is a JS URL, WebKit does not escape < and >.

So: We are now consistent with IE. If something breaks, it runs different code in Firefox and IE. And that’s what Cisco does. If we wanted to go back to escaping < and >, we should probably implement WebKit’s special case of not escaping when an attribute reflects as a URL and contains a javascript: URL. Do we have an evang channel to Cisco? How hard would it be to get them to update their code? Parsing innerHTML output as XML in fundamentally bogus. The relevant code is (reindented) in function cuesGetXmlDoc: if (isIE) { if (nH == null) nL = document.getElementById(id); else { nL = new ActiveXObject("Msxml.DOMDocument"); nL.loadXML(nH); } } else if (isFF || isSafari) { var kK = new DOMParser(); if (nH == null) { nL = kK.parseFromString(document.getElementById(id).innerHTML, "text/xml"); } else nL = kK.parseFromString(nH, "text/xml"); } It seems to me that cloning nodes instead of using innerHTML or DOMParser would be more appropriate here.

(In reply to Henri Sivonen (:hsivonen) from comment #33) > It seems to me that cloning nodes instead of using innerHTML or DOMParser > would be more appropriate here. Umm. No, the root bogosity occurs earlier. They have dumped a massive XML file inline inside an HTML file between <xml> and </xml>. The spec-compliant way to do that would be using <script type=application/xml> and </script> and using DOMParser on the textContent of the script node. Here’s a demo that works cross-browser (in the case of IE, starting with IE9): http://hsivonen.iki.fi/test/moz/xml-data-block.html Better yet, they could have put the XML data in a separate .xml file and retrieve it using XHR in all browsers—including IE earlier than 9.

We'll keep tracking this since it's a large site being affected, but moving to Tech Evang.

I sent email to Cisco Security Products Support and reached out to them on Twitter. Will update when I get a reply.

(In reply to JStagner@Mozilla.com from comment #36) > I sent email to Cisco Security Products Support and reached out to them on > Twitter. Will update when I get a reply. Any reply?

No reply from Cisco what-so-ever. I'll try another route

Tried messaging Cisco via LinkedIn - no replies

At this point we'll untrack - people's heads aren't exploding and we can't get in touch with Cisco to have this fixed on their end.

People's heads aren't exploding because we're finding other browsers to use and/or versions to roll back to and stay with. And we're also being polite, but this is a very big deal for people who use these kinds of appliances day-in and day-out. This is not the way to win favors with the enterprise crowd, guys.

I'm with chode. I'm stuck with either FF14 or Chrome. And good luck getting Cisco's help. This seems to be an odd niche in Cisco. I've had hell getting support (and I paid for it) and had hell finding anyone who can explain "oddities" of these boxes.

Can someone open a bug with Cisco TAC and drop me at email at fluffy@cisco.com to let me know the case number? I don't work with the group that does ACS but I can try to forward it to them. Thanks

I should note that Cisco is pretty keen on making our stuff HTML5 compliant. Whatever that means :-)

(In reply to bugzilla.mozilla.org from comment #41) > People's heads aren't exploding because we're finding other browsers to use > and/or versions to roll back to and stay with. And we're also being polite, > but this is a very big deal for people who use these kinds of appliances > day-in and day-out. This is not the way to win favors with the enterprise > crowd, guys. I’m not at the right Cisco customer level to be able to file a bug on TAC. Can you file a bug on http://tools.cisco.com/ServiceRequestTool/create/launch.do and point out that 1) Passing the string obtained from innerHTML to (new DOMParser()).parseFromString() has always been unsafe in the general case and it just became unsafe in even more cases when we aligned our serializer with the HTML spec and IE. 2) The most proper way to fix this would be putting the XML data in an external file and fetching that via XMLHttpRequest. 3) If there is something in the architecture of the Cisco product that makes a separate file + XHR infeasible, the next most proper technique is the one demoed at http://hsivonen.iki.fi/test/moz/xml-data-block.html ?

Apologies, I did not realize you were waiting on me. I've opened SR#624392031 with Cisco TAC, but I'm not exactly sure how this will resolve the issue with Firefox 15 and newer.

A Cisco engineer contacted me back with a link to this page: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCuc13958 He also said this is fixed in version 5.4 beta 1 of ACS.

Thanks for the feedback. It seems that the bug ticket is private and limited by restricted rights. Anyway, if you have the possibility to test the version 5.4 beta 1 of ACS with Firefox 18 (which is releasing this week) to confirm it's fixed, it would be great!

I did not verify the fix but I did look at the Cisco bug and it looks like it actually is the same bug so I would bet a beer that it actually is fixed given that test signed off on it. It got listed as an enhancement not a bug because the supported version of firefox are, wait for it - drum roll, FF 3 and 4. Really, I can't make this stuff up. At least it does not have IE 6 as supported browser.

(In reply to bugzilla.mozilla.org from comment #47) > A Cisco engineer contacted me back with a link to this page: > > http://tools.cisco.com/Support/BugToolKit/search/getBugDetails. > do?method=fetchBugDetails&bugId=CSCuc13958 > > He also said this is fixed in version 5.4 beta 1 of ACS. Thanks. (In reply to Cullen Jennings from comment #49) > I did not verify the fix but I did look at the Cisco bug and it looks like > it actually is the same bug so I would bet a beer that it actually is fixed > given that test signed off on it. Nice! Thanks. akeybl, since the HTML5-compliance+performance enhancement to the innerHTML getter happened between ESR 10 and ESR 17 and the target audience of ESR is also the target audience of Cisco ACS, it seems to me it would make sense to put the information about the need to get an update from Cisco in whatever release notes or other docs we provide for ESR 10 to 17 migration. Do we have release notes of that kind and do you agree that it would be appropriate to cover this issue in them?

(In reply to Henri Sivonen (:hsivonen) from comment #50) > (In reply to bugzilla.mozilla.org from comment #47) > > A Cisco engineer contacted me back with a link to this page: > > > > http://tools.cisco.com/Support/BugToolKit/search/getBugDetails. > > do?method=fetchBugDetails&bugId=CSCuc13958 > > > > He also said this is fixed in version 5.4 beta 1 of ACS. > > Thanks. > > (In reply to Cullen Jennings from comment #49) > > I did not verify the fix but I did look at the Cisco bug and it looks like > > it actually is the same bug so I would bet a beer that it actually is fixed > > given that test signed off on it. > > Nice! Thanks. > > akeybl, since the HTML5-compliance+performance enhancement to the innerHTML > getter happened between ESR 10 and ESR 17 and the target audience of ESR is > also the target audience of Cisco ACS, it seems to me it would make sense to > put the information about the need to get an update from Cisco in whatever > release notes or other docs we provide for ESR 10 to 17 migration. Do we > have release notes of that kind and do you agree that it would be > appropriate to cover this issue in them? Yep - we'll communicate this outward.

People seem happy with the resolution. FIXED.