Rendering a Cisco ACS page is broken in Firefox 15

RESOLVED FIXED

Status

Tech Evangelism
Desktop
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: bugzilla.mozilla.org, Assigned: JStagner@Mozilla.com)

Tracking

({regression})

unspecified
x86_64
Windows 7
regression

Firefox Tracking Flags

(firefox15 wontfix, firefox16- wontfix, firefox17- affected, firefox18- affected)

Details

Attachments

(6 attachments)

(Reporter)

Description

6 years ago
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.

Comment 1

6 years ago
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.
(Reporter)

Comment 2

6 years ago
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.
(Reporter)

Comment 4

6 years ago
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
(Reporter)

Comment 5

6 years ago
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

Comment 6

6 years ago
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?

Comment 7

6 years ago
Or if it's only a rendering issue, can you save locally the webpage and attach it to the bug?
(Reporter)

Comment 8

6 years ago
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?
(Reporter)

Comment 9

6 years ago
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.
(Reporter)

Comment 10

6 years ago
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
(Reporter)

Comment 11

6 years ago
Created attachment 664671 [details]
Screenshot of the page as seen in Internet Explorer
(Reporter)

Comment 12

6 years ago
Created attachment 664673 [details]
Screenshot of the page as seen in Firefox 15.0.1
(Reporter)

Comment 13

6 years ago
Created attachment 664674 [details]
Screenshot of the source as seen in Firefox 15.0.1

Comment 14

6 years ago
(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.
(Reporter)

Comment 15

6 years ago
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
(Reporter)

Comment 16

6 years ago
Created attachment 664684 [details]
Save Page As
(Reporter)

Comment 17

6 years ago
Created attachment 664685 [details]
Save Frame As

Comment 18

6 years ago
Created attachment 664696 [details]
Screenshot FF15 vs FF8 on Win 7

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.
(Reporter)

Comment 19

6 years ago
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?

Comment 20

6 years ago
(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.
Status: UNCONFIRMED → NEW
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Ever confirmed: true
Keywords: regression, regressionwindow-wanted

Comment 21

6 years ago
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
Component: Untriaged → DOM: Core & HTML
Keywords: regressionwindow-wanted
Product: Firefox → Core

Comment 22

6 years ago
Thanks for narrowing down the reg range.
Blocks: 744830

Comment 23

6 years ago
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?

Comment 25

6 years ago
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.
status-firefox15: --- → wontfix
status-firefox16: --- → wontfix
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: ? → -
tracking-firefox17: ? → +
tracking-firefox18: ? → +
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.
Assignee: nobody → JStagner
Component: DOM: Core & HTML → English US
Product: Core → Tech Evangelism
Version: 15 Branch → unspecified
We'll keep tracking this since it's a large site being affected, but moving to Tech Evang.
(Assignee)

Comment 36

6 years ago
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?
(Assignee)

Comment 38

6 years ago
No reply from Cisco what-so-ever.

I'll try another route
(Assignee)

Comment 39

6 years ago
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.
tracking-firefox17: + → -
tracking-firefox18: + → -
(Reporter)

Comment 41

6 years ago
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.

Comment 42

6 years ago
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.

Comment 43

6 years ago
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

Comment 44

6 years ago
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

?
(Reporter)

Comment 46

5 years ago
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.
(Reporter)

Comment 47

5 years ago
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.

Comment 48

5 years ago
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!

Comment 49

5 years ago
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?
Flags: needinfo?(akeybl)
Keywords: relnote
(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.
Flags: needinfo?(akeybl)
Keywords: relnote
People seem happy with the resolution. FIXED.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Component: English US → Desktop
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.