Closed
Bug 1167067
Opened 10 years ago
Closed 9 years ago
Firefox 38 breaks common server IPMI web interfaces
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1165851
People
(Reporter: spfjpl, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
application/zip
|
Details |
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.
Reporter | ||
Updated•10 years ago
|
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)
Reporter | ||
Comment 2•10 years ago
|
||
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)
Reporter | ||
Comment 3•10 years ago
|
||
Comment 4•10 years ago
|
||
This was broke back in 25 as well. Back to chrome to use IPMI until 39.
Reporter | ||
Comment 5•10 years ago
|
||
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
Reporter | ||
Comment 7•10 years ago
|
||
(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.
Comment 8•10 years ago
|
||
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
status-firefox38:
--- → affected
status-firefox38.0.5:
--- → affected
status-firefox39:
--- → affected
status-firefox40:
--- → affected
status-firefox41:
--- → affected
status-firefox-esr31:
--- → unaffected
status-firefox-esr38:
--- → affected
tracking-firefox-esr38:
--- → ?
Ever confirmed: true
Keywords: regression
Updated•10 years ago
|
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Updated•10 years ago
|
Flags: needinfo?(anujagarwal464)
Comment 9•10 years ago
|
||
This seems like a question for Anne. Sounds like something about the spec may not be web-compatible enough...
Flags: needinfo?(anujagarwal464) → needinfo?(annevk)
Comment 10•10 years ago
|
||
I won't be able to look into this until at least June 10 or so.
Updated•10 years ago
|
Flags: needinfo?(annevk)
Comment 11•10 years ago
|
||
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").
Comment 12•9 years ago
|
||
See bug 1165851 comment 23. This seems like a duplicate?
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Comment 14•9 years ago
|
||
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.
Comment 15•8 years ago
|
||
(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
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•