254842 - Mozilla/Firefox won't configure Belkin wireless router model F5D6231-4

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: English US, defect)

Description

[Tigerwolf]

User-Agent:       Mozilla/5.0 (X11; U; IRIX IP32; en-US; rv:1.4b) Gecko/20030618 Mozilla Firebird/0.6
Build Identifier: Any mozilla/firefox browser

Yet *another* web-administered product can't be configured with Mozilla/Firefox:
Belkin 802.11b Wireless Router model F5D6231-4.

I have prevously reported similar difficulty with D-Link products under bug
#245833 (and confirmed by another user in bug #245675).  A search for 'web based
browser' shows additional reports for Linksys products.  These bugs remain open.

THESE ARE SHOW STOPPER BUGS!  The hardware is totally worthless unless
configured which cannot be done with Mozilla/Firefox.  Any user of these
products will blame Mozilla/Firefox.

(Opera appears to have no problem , and it is assumed IE as well since that, of
course, is all that's mentioned in the factory literature).



Reproducible: Always
Steps to Reproduce:
1. Log into router's web admin page (default 192.168.2.1)
2. Go to LAN Settings page (or any other with entry boxes)
3. Enter some data
4. Press 'APPLY'

Actual Results:  
Nothing.   APPLY button appears to 'press in' but no other action happens.
Entered parameter data is not stored or used.

Expected Results:  
Page should refresh showing router stored parameters have been updated and applied.


Javascript used by router web-based configuration pages is not handled properly
by Mozilla/Firefox.  It may be badly written, or is written to take advantage of
IE 'features/bugs'.

Javascript console reports typical errors such as:

Error: Illegal Character
Error: IsBlank is not defined

Initial bug report on D-Link products was filed under 'evangelism' since it was
unknown if the browser or badly written javascript in the product(s) is to
blame; and D-Link flatly stated they only support IE.  

However, I am elevating this as the problem is much more widespread than
initially observed, affecting multiple products from multiple vendors.  Also,
the initial report has had no apparent action.

If the problem is 'broken' product javascript, then the manufacturers need a
massive campaign to ensure what they write is *NOT* limited to IE.  If the
problem is Mozilla/Firefox javascript engine not handling these scripts, then
that needs to be corrected ASAP.  

More and more consumer products are moving  to web-based
configuration/administration.   The cross-platform universality of using web
rather than custom (read Microsoft-based) confiuration CDs/drivers will be
totally lost if this issue remains unresolved.

Comment 1

[Tigerwolf]

Attachment: Example broken Belkin configuration page

This is the html from one of the affected broken configuration pages in the
subject Belkin wireless router.

Comment 2

[Brendan Eich [:brendan]]

Likely tech. evangelism, starting with DOM level 0.

/be

Comment 3

[Bob Clary [:bc] (inactive)]

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.

Comment 4

[Tigerwolf]

Attachment: <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.

Comment 5

[Tigerwolf]

Attachment: <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.

Comment 6

[Tigerwolf]

(In reply to comment #3)
> 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.

I have attached the .bin files found when the LAN Settings page is saved.

I can't install the UA extension since following the install links on the page
you provided results in:
   The requested URL /uabar/www/uabar.xpi was not found on this server.

The Belkin manual lists tech support at 877 736-5771  (supposedly available
24/7).  I have just now called them, waded through the menus and hold time. 
After describing the problem, I was told they only support Internet Explorer or
Netscape 4.0 (or higher) for  Windoze and Macintosh computers (depspite the fact
the box says Linux will work.  This is the same brain-dead lack of understanding
 exhibited by D-Link's tech support.

In their favor, I did tell them that the problem was broken javascript in the
router and they did take this down along with the suggestion they check the
products using other modern browsers.  I have little hope this will go anywhere
within the company.

When I pressed for a contact, I was told that all such issues go through
sales/customer support at 800 223-5546.  I called there, described the issue
again, and am currently awaiting a call-back from the product manager.  At least
Belkin seems more accessable than D-Link.

If it would be helpful, the router can be set to allow configuration remotely
from any browser.  This will require a password, but I can set up something
temporarily so one of the team can look at the interface directly.  I prefer to
do this in private rather than publish the access password on a public forum.

Comment 7

[Bob Clary [:bc] (inactive)]

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.

Comment 8

[Tigerwolf]

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.

Comment 9

[Brendan Eich [:brendan]]

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

Comment 10

[Bob Clary [:bc] (inactive)]

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.

Comment 11

[Brendan Eich [:brendan]]

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

Comment 12

[Bob Clary [:bc] (inactive)]

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?

Comment 13

[cannedbrain+mozilla]

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 

Comment 14

[cannedbrain+mozilla]

I forgot to mention I already tried to spoof the user agent, pretending to be IE 6, to no avail.

Comment 15

[Chris Lawson (gone)]

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.

Comment 16

[Tigerwolf]

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.