Closed Bug 1167067 Opened 6 years ago Closed 6 years ago

Firefox 38 breaks common server IPMI web interfaces

Categories

(Core :: DOM: Core & HTML, defect)

38 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1165851
Tracking Status
firefox38 --- wontfix
firefox38.0.5 --- wontfix
firefox39 --- fixed
firefox40 --- fixed
firefox41 --- fixed
firefox-esr31 --- unaffected
firefox-esr38 - fixed

People

(Reporter: spfjpl, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36

Steps to reproduce:

Log into Asus, Supermicro, or other common server IPMI web interface (several clearly use the same code, as they look the same). Click on any of the navigational links in the top bar ("Server Health", "Configuration", "Remote Control", etc.).


Actual results:

The navigation bar doesn't work, but instead produces the following errors:

TypeError: oLeftNav is null header_imp.js:415:4
TypeError: TOPNAV.items[_nItem] is undefined header_imp.js:353:8


Expected results:

The browser should display the other pages linked in the top navigation bar.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Could you provide a public (and if possible free) demo or URL to test, please.
Flags: needinfo?(spfjpl)
Unfortunately not, as IPMI interfaces are an inherently insecure thing to put directly on the Internet, and all of ours are on private networks.

I was able to grab a copy of the IPMI firmware image in question (version 2.11 for an Asus ASMB4-iKVM on a Z8PE-D12X motherboard), and use extract-firmware.sh (from https://code.google.com/p/firmware-mod-kit/) to extract the entire web tree. I will attach a zipped copy to this ticket.
Flags: needinfo?(spfjpl)
This was broke back in 25 as well. Back to chrome to use IPMI until 39.
We are using CentOS 6, so this was working for us in 31.6.0 and broke when a recent update switched to the new ESR series with 38.0. I don't actually know if this broke with 38 or somewhere along the way from 31 to 38. Since the version previous to 31 that we used was likely from the 24 ESR series, I probably never would have encountered this issue if it also existed in 25.
(In reply to Scott Feeney from comment #5)
> We are using CentOS 6, so this was working for us in 31.6.0 and broke when a
> recent update switched to the new ESR series with 38.0. I don't actually
> know if this broke with 38 or somewhere along the way from 31 to 38. Since
> the version previous to 31 that we used was likely from the 24 ESR series, I
> probably never would have encountered this issue if it also existed in 25.

I used the tool mozregression, and it's broken for me since FF22.
good=2013-03-16
bad=2013-03-17
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f5b1f9f5804&tochange=0b052daa913c
(In reply to Loic from comment #6)
> I used the tool mozregression, and it's broken for me since FF22.
> good=2013-03-16
> bad=2013-03-17
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=8f5b1f9f5804&tochange=0b052daa913c

It may have broken in 22, but it was apparently fixed at some point after that because I can confirm it is working in 31.6.0 and 31.7.0 (as well as a number of previous releases in that ESR series), but isn't working in 38.0.
Regression of Bug 850517 in Firefox22 was fixed by Bug 888225.

[Tracking Requested - why for this release]: There is worth to fix in ESR version

And latest regression in Firefox38 is as follows

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=797403411392&tochange=6c227c0e4d60

Triggered by: Bug 1075702
Blocks: 1075702
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Flags: needinfo?(anujagarwal464)
This seems like a question for Anne.  Sounds like something about the spec may not be web-compatible enough...
Flags: needinfo?(anujagarwal464) → needinfo?(annevk)
I won't be able to look into this until at least June 10 or so.
Flags: needinfo?(annevk)
Specifically, header_imp.js has code like this:

  var custAttr = document.createAttribute('nItem');
  custAttr.nodeValue = nItem;
  hAnc.setAttributeNode(custAttr);
  hAnc.onclick = function(){
    var _nItem = this.getAttribute('nItem');
    var curPage = TOPNAV.items[_nItem].page;

which is what throws the second exception in comment 0, since _nItem ends up null (because getAttribute tries to get an attribute named "nitem" while the attribute is actually named "nItem").
See bug 1165851 comment 23. This seems like a duplicate?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1165851
ESR 38 was fixed in Bug 1165851, untracking on this bug because it is tracked in that bug. Changing status of ESR to fixed to reflect status in 1165851.
(In reply to Scott Feeney from comment #2)
> Unfortunately not, as IPMI interfaces are an inherently insecure thing to
> put directly on the Internet, and all of ours are on private networks.
> 
> I was able to grab a copy of the IPMI firmware image in question (version
> 2.11 for an Asus ASMB4-iKVM on a Z8PE-D12X motherboard), and use
> extract-firmware.sh (from https://code.google.com/p/firmware-mod-kit/) to
> extract the entire web tree. I will attach a zipped copy to this ticket.

Can write how unpack and pack firmware iKVM?
Thanks
You need to log in before you can comment on or make changes to this bug.