Opened 9 years ago

Last modified 3 years ago

#5972 new bug

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

Reported by: saivert Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: render issue Cc: anevilyak
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by pulkomandy)

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.

Attachments (1)

dd-wrt_webpositive_bezilla.png (148.5 KB) - added by saivert 9 years ago.
screenshot for comparison

Download all attachments as: .zip

Change History (18)

Changed 9 years ago by saivert

screenshot for comparison

comment:1 Changed 9 years ago by michaelvoliveira

Please report this bug at

http://mmlr.dyndns.org/timeline

Someone please set it to invalid

comment:2 Changed 9 years ago by 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"?

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by saivert

This bug is still present in build hrev515.

comment:5 Changed 7 years ago by 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!

comment:6 Changed 5 years ago by 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!

comment:7 Changed 5 years ago by anevilyak

Cc: anevilyak added
Version: R1/alpha2R1/Development

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.

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by pulkomandy

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

comment:10 Changed 5 years ago by pulkomandy

Description: modified (diff)

Does hrev47543 improve the situation?

comment:11 Changed 5 years ago by saivert

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

comment:12 Changed 5 years ago by anevilyak

Description: modified (diff)

Will give it a try after work.

comment:13 Changed 5 years ago by 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.

Last edited 5 years ago by anevilyak (previous) (diff)

comment:14 Changed 5 years ago by pulkomandy

Description: modified (diff)

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

comment:15 Changed 5 years ago by anevilyak

Description: modified (diff)

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?

comment:16 Changed 5 years ago by pulkomandy

Description: modified (diff)

Yes, building the network kit in debug mode will make the HTTP code trace all requests to the standard output. This may provide more hints as to what is going on.

comment:17 Changed 3 years ago by pulkomandy

Description: modified (diff)

Hi, If this is still a problem, a capture of HTTP requests as suggested in the previous comment would be helpful.

Note: See TracTickets for help on using tickets.