Created attachment 155531 [details] Example broken Belkin configuration page This is the html from one of the affected broken configuration pages in the subject Belkin wireless router.
Likely tech. evangelism, starting with DOM level 0. /be
The interesting things are probably in the script located at lan_settings_files/shared. Tigerwolf, there are a couple of things you can do to help us figure this out. If you can change the ua string temporarily to MSIE, does the source and/or error messages change ? Can you attempt to get a contact at Belkin who we can work with ? <http://uabar.mozdev.org/> can be used to switch ua strings.
Created attachment 155614 [details] <router>/lan_settings_files/main_router.bin This is one of two .bin sub-files saved with the router's LAN Settings page. Other files beyond the two .bin ones are simply decorative .gif ones.
Created attachment 155615 [details] <router>/lan_settings_files/shared.bin This is the second of two .bin sub-files saved from the router's LAN Settings page. The other sub-files are simply decorative .gif ones.
Looks like the problem is a null byte at the end of shared.bin. Error: illegal character Source File: http://localhost/2004/08/09/shared.js Line: 262, Column: 1 Source Code: } Error: isBlank is not defined Source File: http://localhost/2004/08/09/lan_settings.html Line: 62 Removing the bad byte fixes the isBlank error.
This is follup regarding conversation with Belkin Customer Support: I received the callback, but it was not from the router product manager, but from a person who said they were the escallation manager with customer support. The person I spoke with seems familiar with open-source and with the fact there are a number of alternate browsers out there. However, the current official stance is they simply do not support open source browsers, only the ones listed in the manual (IE 4 and NS 4.0 and above). They did indicate that they 'might eventually expand the demographic', but stated that they 'see no problem' with the situation as it is in not supporting or testing with Mozilla/Firefox. This is partly because the box 'works with' Linux/Unix...even if it can't be configured by them when using open source browsers. (!) They also would not provide a named contact to me as I am an 'end user' but they did indicate that they would respond to a call from a Mozilla development team member and direct them to the appropriate people within Belkin. The avenue for this is to call 800 To Belkin (800 223-5546). They also indicated they would *NOT* take any end user input regarding particular soft/firmware issues or fixes. As my intent here is only to get the proper Mozilla team people in communication with the proper Belkin people, this is of little consequence to me personally. It does sound like an appropriate issue for the evangelism team as well as those of you who would deal with isolating which side of the fence the lack of compatibility lies. It's my goal just that the issue be *fixed*. I hope someone on the team will follow this (as well as the D-Link bug) through and post the result here. As an incetive to this process, I mentioned to Belkin that they'd very likely garner development team help in pointing out problems/solutions if they'd just *donate* a router to the team. They seemed receptive to this notion...and the things are really cheap, so it's not like asking much from them. I would also stress that the web admin page provided as an example in this bug report is *NOT* the only page exhibiting the problems described, it's just an example. Before this problem is considered fixed, the router configuration pages should all be functional.
Bob, should this be confirmed and TE, or should it be some likely-WONTFIX'd demand that we ignore nul bytes at the end of .bin, er, .js files? /be
I was waiting to hear your response to the null byte stuff. I have seen null bytes before especially in server side cgi output, but I am ok with telling them to fix their file and not include null bytes if that is the right thing ® Your choice.
ECMA-262 section 7 defines the lexical grammar, and no production specified there produces a lexeme containing \u0000. We could hack our DOM embedding code that handles script tags, or perhaps the HTML content sink (yeah, better to localize the hack) that processes script, to trim trailing NULs included in the script's content. That might buy us some compatibility, but it's yet another little bit of code bloat and complexity wasting time and space. Is it worth it, or should we try to evangelize? Sounds like Belkin could be made to see the light, but it wouldn't help in the short-to-medium term. /be
let's hold our ground until there is more of a justification for the bloat. -> TE Can someone with a mozilla.org address contact them?
Assignee: general → english-us
Status: UNCONFIRMED → NEW
Component: DOM: Level 0 → English US
Ever confirmed: true
Product: Browser → Tech Evangelism
QA Contact: pschwartau → english-us
Version: Trunk → unspecified
I'm having the same problem with Camino and Firefox OS X. It worked fine when checking "Automatic from ISP" but it refused to refresh when doing otherwise. It with Safari however. These are the errors from console.log: http://home.earthlink.net/~cannedbrain/errors.txt And these are the source files: http://home.earthlink.net/~cannedbrain/wan_dns.html http://home.earthlink.net/~cannedbrain/shared.js http://home.earthlink.net/~cannedbrain/main_router.css
I forgot to mention I already tried to spoof the user agent, pretending to be IE 6, to no avail.
INCOMPLETE due to lack of activity since the end of 2009. If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself. Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
Replying to e-mail request to comment. It seems some progress was being made, then dropped without any final determination of whether Mozilla/FF was not interpreting properly something it should, or if Moz/FF was doing the right thing with improper instructions. If the former, then whatever it was hopefully has been fixed in the intervening 7 (!) years. I no longer have that router (since I couldn't use FF with it, and I wasn't about to configure a Windoze box solely for the purpose). If the latter, (i.e. router code was bad), then the manufacturer(s) needed to be given guidance in creating correct code. MS was documented in trial records as doing things that made non-MS OS products 'break' in subtle ways that would leave the user blaming the non-MS OS/browser, so nailing these sorts of things *should* be important to FF developers. Now that FF is a recognized contender, I *hope* most manufacturers test their products with FF as well as others. However, the notion that 'we only support Windoze, or IE' is still one that needs to be hammered as unacceptable by the FF community I must take great exception to the last comment in bug #245833 (involving D-Link routers) that 'since it works with current D-link products, we don't care'. This is myopic, *UNLESS* the answer to whether a manufacturer needs evangelism to correct bad code, or if FF needs to correct it's handling of the code it gets is definitively resolved. Just dropping issues with no real resolution is not really fixing them.
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.