1646 - javascript: [DOGFOOD] URLs aren't working

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[cpratt]

At the URL listed in this bug report, you can select a product to price and then
click the Go button to go to a page that displays further product information.
When you do this using seamonkey, the Go button links to "javascript//" instead
of
"JavaScript:gotoUrl(document.ProductSelection.systems.options[document.ProductSel
ection.systems.selectedIndex].value)".

Comment 1

[Peter Trudelle]

batch-reassigning all Garrett Blythe bugs to Don Melton

Comment 2

[don]

Re-assigned to [e-mail].

Vidur, since this isn't an xpapps issue, do you who should get this bug?

Comment 3

[vidur (gone)]

Known problem with javascript: URLs after Warren's URL parsing checkin.

Comment 4

[leger]

Setting all current Open/Normal to M4.

Comment 5

[vidur (gone)]

*** Bug 3345 has been marked as a duplicate of this bug. ***

Comment 6

[Paul MacQuiddy]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 7

[cbegle]

DOM bugs are not my problem.

Comment 8

[vidur (gone)]

*** Bug 1708 has been marked as a duplicate of this bug. ***

Comment 9

[gerardok]

QA contact re-assigned according to the product areas we're currently working
on.

Comment 10

[vidur (gone)]

I'm waiting for the new netlib before I rewrite javascript: processing.

Comment 11

[vidur (gone)]

*** Bug 1919 has been marked as a duplicate of this bug. ***

Comment 12

[vidur (gone)]

*** Bug 5540 has been marked as a duplicate of this bug. ***

Comment 13

[vidur (gone)]

*** Bug 5412 has been marked as a duplicate of this bug. ***

Comment 14

[vidur (gone)]

*** Bug 5840 has been marked as a duplicate of this bug. ***

Comment 15

[joki (gone)]

*** Bug 6222 has been marked as a duplicate of this bug. ***

Comment 16

[harishd]

*** Bug 5410 has been marked as a duplicate of this bug. ***

Comment 17

[vidur (gone)]

Wallet code does not need to use javascript: URLs. It should be updated to use
onclick handlers instead.

Comment 18

[vidur (gone)]

Brendan is going to help out with javascript: URLs.

Comment 19

[Stephen P. Morse]

Admittedly the onclick handler could be used and wallet would not be blocked.
But that handler is giving me trouble as well (see bug report 6580).  So until
either this bug or bug 6580 is fixed, wallet is still blocked.

Comment 20

[vidur (gone)]

*** Bug 6587 has been marked as a duplicate of this bug. ***

Comment 21

[brendan-obsolete]

I'm not going to fix JavaScript URLs till after XPCOM2 and parts of Necko show
up, so morse's best bet is pollman fixing 6580.

/be

Comment 22

[leger]

Moving to DOM Level 0 component.  Move to DOM Level 1 if that is more correct.

Comment 23

[brendan-obsolete]

This is more netlib than DOM.

/be

Comment 24

[Stephen P. Morse]

Stop before you go blaming this on netlib.  My original report, 5410, had
nothing to do with netlib.  That bug has since been marked as a duplicate of
this one.  If this one is a netlib bug, then perhaps whomever marked these two
bugs as duplicates was in error.

In any event, bug 5410 is currently seriously blocking wallet and cookie work.
I am unable to get a working cookie viewer or signong viewer until this is
fixed.  As a demo, click on the menu item edit/wallet/view-cookies (or view
signons).  You'll see tabs at the top.  But clicking on these tabs does not
change the display (it should).  No netlib involved here.

Comment 25

[brendan-obsolete]

Steve, I still own this bug.  I'm setting its component category to netlib cuz
that's where the javascript: URL method will be handled, by code I write.  Why
do you think I'm "blaming netlib" by changing the component to reflect where the
lack of functionality lies?  Why are you bringing up "blame" at all?

This is about the third time you've complained about how you're so very blocked.
I have already marked this bug M8, and I'm not going to be able to fix it any
sooner, because I need necko for its URL handling interfaces.  But I'm tired of
hearing complaints about blockage, and useless finger-pointing (I'm all for bug
accountability, on the other hand).  So I have a suggestion: spend some of the
time you're wasting repeating your dependency complaints on helping pollman fix
the onclick bug (6580), to which javascript: URLs were a workaround.  Maybe that
could be fixed sooner than M8.

I know, it's not your bug or area of expertise.  But sometimes a helping hand is
worth more than complaints, however righteous.  Neither you nor I can speed up
necko's landing, so it seems better to push on 6580.  Let me know if I can help
(I'm able as soon as I scrape my Linux build off the floor).

Comment 26

[vidur (gone)]

*** Bug 7506 has been marked as a duplicate of this bug. ***

Comment 27

[leger]

*** Bug 8789 has been marked as a duplicate of this bug. ***

Comment 28

[brendan-obsolete]

Need Necko, so M9.

/be

Comment 29

[Eric Pollmann]

See bug 9009

Comment 30

[Eric Pollmann]

Opps, nevermind.  I didn't realized that javascript: was already in the protocol
hash table pointing at the nsHttpURLFactory...  Hmmm...

Comment 31

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 32

[brendan-obsolete]

*** Bug 10795 has been marked as a duplicate of this bug. ***

Comment 33

[Paul MacQuiddy]

*** Bug 6164 has been marked as a duplicate of this bug. ***

Comment 34

[brendan-obsolete]

I'm removing [BLOCKING WALLET] because 6580, for which javascript: was a
workaround, appears to be fixed but left open till M12 as a reminder to look for
similar bugs.

I'm this close to implementing javascript: (modulo new bugs such as conversion
to ASCII foisted on us by netlib's byte-buffer i/o model).

/be

Comment 35

[leger]

Is this checked in to M9 branch?

Comment 36

[leger]

Moving to Resolved/Fixed per brendan mail to me 08/23 that fix was checked into
M9 branch.

Comment 37

[leger]

*** Bug 7547 has been marked as a duplicate of this bug. ***

Comment 38

[Prashant Desale]

Reopening this bug.

I tested it with M9 as well as M10 builds and aI'm afraid that its not working
for both.

M9 Build [08-24-13]:
After clicking button "Go" it gives error gotoUrl is not defined. gotoUrl is a
function defined in javascript.
This works fine with Communicator 4.5

M10 Build [08-24-09]
For M10 it does not even give that error and niether it goes to page it is
supposed to go.

Comment 39

[leger]

M9 is leaving the station...moving to M10

Comment 40

[cpratt]

My test results were the same as desale's.

Comment 41

[brendan-obsolete]

gotoUrl not defined has nothing to do with my changes, file a separate bug
please, to whomever owns navigator.xul and navigator.js.

This so works in every M9 binary I've tested, but again, it was busted in the
trunk (M10, I suppose) by norris's security changes.  We're working on fixing it
and I won't close this bug till then.  Actually, I didn't close this bug yet,
myself -- Jan, did you close it?  I'd like to be in charge of closing my own
bugs, if you don't mind.

/be

Comment 42

[ekrock's old account (dead)]

According to Microsoft, this bug is also currently blocking Microsoft from
supporting Nav5 in the next version of PowerPoint. Contact there is Marcus Aiu
<[e-mail]>. The sooner we can fix, the sooner they can continue
development.  Their "Goto" feature depends on this.  Asked Marcus to add self to
this cc: list so he's aware of status.

Comment 43

[brendan-obsolete]

*** Bug 3388 has been marked as a duplicate of this bug. ***

Comment 44

[Yossi Oren]

*** Bug 14978 has been marked as a duplicate of this bug. ***

Comment 45

[Brendan Eich [:brendan]]

*** Bug 15908 has been marked as a duplicate of this bug. ***

Comment 46

[Yossi Oren]

Just wanted to note that this bug ruins that incredibly popular game,
Wak-a-Nixon, situated at http://www.superpants.com/wnix

BTW, visited www.microsoft.com using 1999101216/WinNT - CSS works!  You get
hover-underlined links all over the site!  Yay!

Comment 47

[cbegle]

*** Bug 15632 has been marked as a duplicate of this bug. ***

Comment 48

[Mike McCabe]

*** Bug 16102 has been marked as a duplicate of this bug. ***

Comment 49

[Mats Palmgren (inactive)]

*** Bug 16451 has been marked as a duplicate of this bug. ***

Comment 50

[Mats Palmgren (inactive)]

javascript: URLs are now crashing on all platforms, raising to critical.
See bug 16451 for stack dumps.

Comment 51

[Mats Palmgren (inactive)]

*** Bug 16387 has been marked as a duplicate of this bug. ***

Comment 52

[Brendan Eich [:brendan]]

Doug did it ;-)  Seriously, dougt helped a lot in unregressing javascript:,
which worked in M9 but broken soon after when about: and other URL loading moved
to a file worker thread.  Reassigning to dougt, I'm away till Tuesday.

/be

Comment 53

[Doug Turner (:dougt)]

me break things?  naa.  :-)

The problem is in nsJSProtocolHandler::NewChannel, we are checking to see the
subject has a principal by calling HasSubjectPrincipal(), and it fails (for
whatever reason).  Then we are returning NS_OK and the caller uses the uninited
channel and dies horribly.

Since this is what norris was working on (principle stuff), I am going to
reassign this to him.

Comment 54

[Norris Boyd]

I need to find the document that was active when the user clicked on the link.
However, that information is not available when I get control. In 4.x the
URL_Struct had a referrer field that we used to propagate this information. I'll
need to find some help on this.

The stack is
nsJSProtocolHandler::NewChannel(nsJSProtocolHandler * const 0x02d2d7d0, const
char * 0x002bcec8, nsIURI * 0x032728f0, nsILoadGroup * 0x0283f3a0,
nsIEventSinkGetter * 0x03266050, nsIChannel * * 0x0012f270) line 224
nsIOService::NewChannelFromURI(nsIOService * const 0x0116ee80, const char *
0x002bcec8, nsIURI * 0x032728f0, nsILoadGroup * 0x0283f3a0, nsIEventSinkGetter *
0x03266050, nsIChannel * * 0x0012f2b4) line 229 + 43 bytes
NS_OpenURI(nsIChannel * * 0x0012f388, nsIURI * 0x032728f0, nsILoadGroup *
0x0283f3a0, nsIEventSinkGetter * 0x03266050) line 63 + 33 bytes
nsDocumentBindInfo::Bind(nsIURI * 0x032728f0, nsILoadGroup * 0x0283f3a0,
nsIInputStream * 0x00000000, const unsigned short * 0x03272e20) line 1057 + 49
bytes
nsDocLoaderImpl::LoadDocument(nsDocLoaderImpl * const 0x0283f480, nsIURI *
0x032728f0, const char * 0x002bc1e4, nsIContentViewerContainer * 0x0283e610,
nsIInputStream * 0x00000000, nsISupports * 0x00000000, unsigned int 0x00000000,
const unsigned int 0x00000000, const unsigned short * 0x03272e20) line 508 + 32
bytes
nsWebShell::DoLoadURL(nsIURI * 0x032728f0, const char * 0x002bc1e4,
nsIInputStream * 0x00000000, unsigned int 0x00000000, const unsigned int
0x00000000, const unsigned short * 0x03272e20) line 2115 + 57 bytes
nsWebShell::LoadURI(nsWebShell * const 0x0283e610, nsIURI * 0x032728f0, const
char * 0x002bc1e4, nsIInputStream * 0x00000000, int 0x00000001, unsigned int
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const
unsigned short * 0x03272e20) line 2181 + 32 bytes
nsWebShell::LoadURL(nsWebShell * const 0x0283e610, const unsigned short *
0x032678f0, const char * 0x002bc1e4, nsIInputStream * 0x00000000, int
0x00000001, unsigned int 0x00000000, const unsigned int 0x00000000, nsISupports
* 0x00000000, const unsigned short * 0x03272e20) line 2341 + 52 bytes
nsWebShell::LoadURL(nsWebShell * const 0x0283e610, const unsigned short *
0x032678f0, nsIInputStream * 0x00000000, int 0x00000001, unsigned int
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const
unsigned short * 0x03272e20) line 1917
nsWebShell::HandleLinkClickEvent(nsIContent * 0x031f51fc, nsLinkVerb
eLinkVerb_Replace, const unsigned short * 0x032678f0, const unsigned short *
0x10068170 gCommonEmptyBuffer, nsIInputStream * 0x00000000) line 3021
OnLinkClickEvent::HandleEvent() line 2844
HandlePLEvent(OnLinkClickEvent * 0x03267dc0) line 2857
PL_HandleEvent(PLEvent * 0x03267dc0) line 534 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01122f10) line 493 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00310266, unsigned int 0x0000c0da, unsigned int
0x00000000, long 0x01122f10) line 963 + 9 bytes
USER32! 77e71820()
01122f10()

Comment 55

[Norris Boyd]

Marking dogfood.

Comment 56

[Norris Boyd]

I believe I have the changes necessary to get the javascript: URLs running under
the correct principals. Unfortunately, this page still doesn't work.

I've investigated the remaining problem. The JavaScript code invoked from the
javascript: URL works by assigning to window.location. It assigns a relative
URL, expecting the browser to compute an absolute URL. Unfortunately, it
computes this absolute URL by first getting what it believes to be the URL of
the current page, but that is the javascript: url!  This code is in
LocationImpl::GetSourceURL in mozilla/dom/src/base/nsLocation.cpp.

Comment 57

[Norris Boyd]

Checked in my changes.
Reassigning to vidur since he wrote the nsLocation code.

Comment 58

[Nisheeth Ranjan]

Vidur has too many bugs on his plate.  I'm re-assigning this to myself to take a
look into.  I'll pick his brains if I get stuck!

Comment 59

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's not entirely clear to me from everything this bug has gone through, but...

Is the problem for which this bug is now open that "javascript:" URLs are
allowed to be considered the URL of a page?  Really, they should just cause code
to be executed without changing the idea of the "current page", right?  (unless,
of course, the JS changes the "current page")

(What I'm describing can be seen by clicking the links in
http://ww2010.atmos.uiuc.edu/(Gl)/wx/satellite.rxml - in NN4.x the new window
opens for the link (by JS) and the old window holds the same thing it did, but
currently in Mozilla, the old window is replaced by a blank one with a
javascript: URL at the top.)

Comment 60

[Nisheeth Ranjan]

David, you hit the nail right on the head.

Travis, it seems like the webshell is replacing its url with the javascript: url
in nsWebShell::LoadURL() before the javascript: url has started being processed
by necko.  The webshell should not be changing its notion of the current url so
eagerly.  In this case, loading a javascript: url does not necessarily imply
that the current document will change.  That change will only happen if
either the javascript: url returns a string that contains HTML or the javascript
referred to by the javascript: url causes a new document load.

This bug is happening because the javascript code referred to by the javascript:
url sets the location property of the document which fails as Norris described
in his earlier post.

I'm going to bring up this bug at the porkjockeys meeting today and discuss
possible solutions.  Adding Travis to the cc list.

Comment 61

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(BTW, I think the webshell changes its notion of current URL too quickly in
other cases.  When loading a doc, you shouldn't change the URL in the URLbar or
destroy the old doc until you've done a DNS lookup and gotten through the the
server.  Right now, the URL bar changes instantly and the link becomes visited
if I click on one of the "unvisited" links in
http://www.fas.harvard.edu/~dbaron/css/test/pseudos2 , even though the host
doesn't exist.  (I'm slightly surprised that the relative link ("visited")
worked after that.  Perhaps it's because of the error.  What would happen if the
DNS lookup worked and the host didn't respond.)  See bug 6882 for further
discussion of this.

This should really be a separate bug...)

Comment 62

[Mike McCabe]

*** Bug 17343 has been marked as a duplicate of this bug. ***

Comment 63

[Mike McCabe]

*** Bug 16802 has been marked as a duplicate of this bug. ***

Comment 64

[Mike McCabe]

*** Bug 15267 has been marked as a duplicate of this bug. ***

Comment 65

[Nisheeth Ranjan]

I have a fix for this in my tree.  Now, we only set the url and the referrer
attributes on the webshell after the nsDocLoaderImpl::LoadDocument() call from
nsWebShell::DoLoadURL() returns successfully.  During the load of a
javascript: url, the LoadDocument() call ends up calling
nsJSProtocolHandler::NewChannel().  For the case where the javascript associated
with the javascript: url returns an undefined return value, an error code
(NS_ERROR_DOM_RETVAL_UNDEFINED) is returned from
nsJSProtocolHandler::NewChannel() back up to nsWebShell::DoLoadURL() and the url
and referrer properties are left unchanged.  For the case where the javascript:
url returns a generated document, a new channel is created by the JS protocol
handler, a success code is returned back to nsWebShell::DoLoadURL(), and the url
and referrer properties are changed appropriately.

nsWebShell::GetReferrer() was used earlier by the security code in the JS
protocol handler to get access to the parent url of the javascript: url.  Now,
since the parent url is not replaced with the javascript: url in the webshell,
the security code uses the nsWebShell::GetURL() method.  I've exorcised the
GetReferrer() method from nsIWebShell because the JS protocol handler was
the method's only consumer.

I'll check this stuff in after some more testing tomorrow.

Comment 66

[Nisheeth Ranjan]

My changes were reviewed by norris, warren, and radha.  I've been waiting for
some session history API changes from Radha.  Radha's stuff is checked in now,
so I just checked in my changes.

Comment 67

[Prashant Desale]

Tested with 1999-11-11-09 with Win-95. Working fine, Marking verified.

Comment 68

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.

Comment 69

[benc]

*** Bug 7398 has been marked as a duplicate of this bug. ***