DD-WRT administration interface not rendered properly. javascript issues too

[saivert]

DD-WRT is a nice third-party firmware interface for a host of cheap wireless routers, most prominently Broadcom based routers like Linksys WRT54G. It has a nice web based administration interface, but this interface is not rendered properly in WebPositive build hrev488 on Haiku r1alpha2.

Provided is screenshot with BeZillaBrowser used as reference since it renders the interface properly and also handles the JavaScript used on the page.

[saivert]

screenshot for comparison

[michaelvoliveira]

Please report this bug at

​http://mmlr.dyndns.org/timeline

Someone please set it to invalid

[stippi]

It's ok to report WebPositive issues here.

But from the screenshot, I don't see what the big problem is. Some frames are missing, but the interface looks functional. For all I know, it could be a problem in the page and not WebPositive. Also, could you explain what is non-functional about the Javascript? How about other WebKit browsers, do they all render this interface "correctly"?

[saivert]

Chrome, Opera and Internet Explorer handles the DD-WRT web interface ok. Everything works.

The page has some CSS for the FIELDSET tags (the groupbox like elements on the page) which only looks as it is supposed to on Firefox/BeZillaBrowser.

Following JavaScript snippet is the function that is called by the "Add" button on the page. This sets some form (identified by F) values then submits the form.

function forward_add_submit(F) {
F.change_action.value="gozila_cgi";
F.submit_type.value = "add_forward_spec";
apply(F);
}

This is the "apply" function:

function apply(form, text, delay) {
	form.submit();
	for (i = 0; i < form.elements.length; i++) {
		if(defined(form.elements[i].disabled)) 
			form.elements[i].disabled = true;
	}
	if (form.contents) document.getElementById("contents").style.color = '#999999';
}

so it seems like WebPositive's handling of the form submit from javascript is the culprit here. When that is executed it comes with an error message:

Error loading ​http://192.168.1.1/apply.cgi Server returned norhing (no headers, no data)

The other browser happily submit the form when called from javascript.

[saivert]

This bug is still present in build hrev515.

[mmadia]

Hi. Our WebKit port (and thus WebPositive) was updated in July. Could you retest this in a new nightly image and report back? ​http://www.haiku-files.org/haiku/development Thanks!

[pulkomandy]

Our WebKit port was updated again last week. Could you retest this in a new nightly image and report back? ​​http://www.haiku-files.org/haiku/development Thanks!

[anevilyak]

Will check tonight, my router runs this as well. Since it was primarily AJAX issues similar to those seen with GMail, I suspect this is likely to be resolved though.

[anevilyak]

The interface renders properly from a visual standpoint, but something's still wrong as far as actually handling it goes. Clicking any of its tabs to go to the corresponding configuration subsection triggers the appropriate http digest authentication dialog, but after one enters credentials, Web+ simply sits there waiting, seemingly for a response, until finally failing with a network read error several minutes later.

[pulkomandy]

There may be bugs in our http auth code. It was only tested with dev.haiku-os.org so far.

[pulkomandy]

Does hrev47543 improve the situation?

[saivert]

I have no immediate way to verify this as I no longer use DD-WRT.

[anevilyak]

Will give it a try after work.

[anevilyak]

Seems there's still an issue with this one: while browsing through the interface generally works, attempting to apply/save settings winds up hitting the interface's apply.cgi and then stopping dead without actually executing it properly. Tested with hrev47561 and DD-WRT v24.

[pulkomandy]

Does hrev47586 (and especially a1cce97) help with this remaining issue? I'm only guessing here, but this fixed some other cases of stalling requests.

[anevilyak]

Doesn't appear to have made a difference, unfortunately. Web+ does indicate that the apply.cgi request finished both before and after that change, but simply stops there. Is there any network traffic tracing that could be enabled or whatnot, that might yield a better picture of what's going on?