179269 - New page opens which should display tabular data. Error message in new page instead of data.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Sam Drinkard]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

The noaa wave watch III page is a java-based page that can display a time series
of wave heights, peak periods, and wind speeds. Several options exist to display
as well, tabular data for each individual stations particular data.  The tabular
data is accessed via clicking on a "box" icon ON the map.

Reproducible: Always

Steps to Reproduce:
1. Select the following boxes from the drop-down menus. Default on "latest model
run".  Select either "nowcast" or any individual hour.  Select (for location)
WNA US coastal zoom (regional). Select wave heights. The default box for
"Bulletin" is checked, and should be.

2. Click on the "go" button, which will display a map in the current window.

3. Click on any square station box, which will open a new window.

Actual Results:  
After performing the above steps, you have the main window, and one new window.
The new window has the error message "Sorry, cannot execute the request.."

Expected Results:  
Page should display the tabular data. Checking the page info via Netscape 4.7
under windows 98 discloses the page URL of
http://polar.wwb.noaa.gov/cgi-bin/nww3_bull.cgi?1&latest_run/wna.41004

The same identical problem exists under Mozilla v. 1.2b, and it gives the same
error message in the new window. As far as I know, my configuration is such that
that I don't think I have anything disabled security-wise to prevent the display
of the contents.  Typing in the URL of the tabular data by hand will display the
contents, and is in HTML format.

Comment 1

[Andrew Schultz]

I'm seeing this with linux trunk build 20021109.  JS Debugger says that
location.pathname (line 2212 of http://polar.wwb.noaa.gov/waves/main_int.js) is
empty.  loading it locally works fine.

marking NEW
==> DOM 0 ?

Comment 2

[Harshal Pradhan]

Attachment: proposed fix

The problem here is that some script is relying on the value of
location.pathname when the page itself was generated by a document.write(). 

nsLocation uses the nsIWebNavigation interface of docshell to get the url for
figuring out the patch name, and this happens to be the wyciwyg:// url
corresponding to the document.write(). Pathname for this ends up a null string
and the script thus fails.

The fix is to check for these urls and if found return the underlying "real"
url. I just copied similar code from http 
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#2545

and it fixes the problem. 

However, maybe some more thought should go into this, code for fixing up these
urls is starting to appear in multiple places in the tree. Also,
nsIWebNavigation is an interface embeddors too are encouraged to use right?
Should this fixup really be happening in docshell, so that nsIWebNavigation
always returns "correct" urls? Will that break anything?

Comment 3

[Harshal Pradhan]

Comment on attachment 107890 [details] [diff] [review]
proposed fix

caillon told me I should be using nsIURIFixup.

Comment 4

[Harshal Pradhan]

Taking bug, I'll attach a better patch shortly.

Comment 5

[Harshal Pradhan]

Attachment: proposed fix (use nsIURIFixup to get an exposable url)

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 108456 [details] [diff] [review]
proposed fix (use nsIURIFixup to get an exposable url)

sr=jst

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 108456 [details] [diff] [review]
proposed fix (use nsIURIFixup to get an exposable url)

Use the constant defined in nsCDefaultURIFixup for the contractid, instead of
the string literal.

Comment 8

[Harshal Pradhan]

Attachment: use the constant like caillon suggested.

Comment 9

[Harshal Pradhan]

Comment on attachment 108662 [details] [diff] [review]
use the constant like caillon suggested.

carrying over jst's sr and caillon review over to new patch. (I'll ask someone
to checkin after the tree un-freezes after 1.3a.)

Comment 10

[Harshal Pradhan]

caillon, can you please check this in whenever its convenient.

Comment 11

[Harshal Pradhan]

caillon, thanks for checking this in. This is now fixed. 

Comment 12

[Sam Drinkard]

Thanks to all involved and made the fix..