Closed Bug 1646 Opened 26 years ago Closed 25 years ago

javascript: [DOGFOOD] URLs aren't working

Categories

(Core :: Networking, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: nisheeth_mozilla)

References

()

Details

(Keywords: testcase, Whiteboard: [PDT+])

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)".
batch-reassigning all Garrett Blythe bugs to Don Melton
Assignee: don → vidur
Re-assigned to vidur@netscape.com. Vidur, since this isn't an xpapps issue, do you who should get this bug?
Status: NEW → ASSIGNED
Known problem with javascript: URLs after Warren's URL parsing checkin.
Setting all current Open/Normal to M4.
*** Bug 3345 has been marked as a duplicate of this bug. ***
Component: Windows FE → JavaScript
Product: MozillaClassic → Browser
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
DOM bugs are not my problem.
*** Bug 1708 has been marked as a duplicate of this bug. ***
QA Contact: 4015 → 4616
QA contact re-assigned according to the product areas we're currently working on.
Summary: Links to pages defined using JavaScript aren't working → javascript: URLs aren't working
Target Milestone: M4 → M5
Target Milestone: M5 → M6
I'm waiting for the new netlib before I rewrite javascript: processing.
*** Bug 1919 has been marked as a duplicate of this bug. ***
*** Bug 5540 has been marked as a duplicate of this bug. ***
*** Bug 5412 has been marked as a duplicate of this bug. ***
*** Bug 5840 has been marked as a duplicate of this bug. ***
*** Bug 6222 has been marked as a duplicate of this bug. ***
*** Bug 5410 has been marked as a duplicate of this bug. ***
Summary: javascript: URLs aren't working → [BLOCKING WALLET] javascript: URLs aren't working
Summary: [BLOCKING WALLET] javascript: URLs aren't working → javascript: URLs aren't working
Wallet code does not need to use javascript: URLs. It should be updated to use onclick handlers instead.
Assignee: vidur → brendan
Status: ASSIGNED → NEW
Brendan is going to help out with javascript: URLs.
Summary: javascript: URLs aren't working → [BLOCKING WALLET] javascript: URLs aren't working
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.
*** Bug 6587 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
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
Blocks: 7530
Component: JavaScript → DOM Level 0
Moving to DOM Level 0 component. Move to DOM Level 1 if that is more correct.
Component: DOM Level 0 → Networking Library
This is more netlib than DOM. /be
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.
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).
*** Bug 7506 has been marked as a duplicate of this bug. ***
*** Bug 8789 has been marked as a duplicate of this bug. ***
Target Milestone: M8 → M9
Need Necko, so M9. /be
Opps, nevermind. I didn't realized that javascript: was already in the protocol hash table pointing at the nsHttpURLFactory... Hmmm...
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. ;-)
*** Bug 10795 has been marked as a duplicate of this bug. ***
*** Bug 6164 has been marked as a duplicate of this bug. ***
Summary: [BLOCKING WALLET] javascript: URLs aren't working → [Fix almost in hand] javascript: URLs aren't working
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
Summary: [Fix almost in hand] javascript: URLs aren't working → javascript: URLs aren't working
Whiteboard: Fix almost in hand
Blocks: 3388
Blocks: 11963
Is this checked in to M9 branch?
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Moving to Resolved/Fixed per brendan mail to me 08/23 that fix was checked into M9 branch.
*** Bug 7547 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Target Milestone: M9 → M10
M9 is leaving the station...moving to M10
My test results were the same as desale's.
Status: REOPENED → ASSIGNED
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
According to Microsoft, this bug is also currently blocking Microsoft from supporting Nav5 in the next version of PowerPoint. Contact there is Marcus Aiu <marcusa@microsoft.com>. 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.
Depends on: 14049
*** Bug 3388 has been marked as a duplicate of this bug. ***
Blocks: 14327
*** Bug 14978 has been marked as a duplicate of this bug. ***
*** Bug 15908 has been marked as a duplicate of this bug. ***
OS: Windows 95 → All
Hardware: PC → All
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!
*** Bug 15632 has been marked as a duplicate of this bug. ***
*** Bug 16102 has been marked as a duplicate of this bug. ***
*** Bug 16451 has been marked as a duplicate of this bug. ***
Severity: normal → critical
javascript: URLs are now crashing on all platforms, raising to critical. See bug 16451 for stack dumps.
*** Bug 16387 has been marked as a duplicate of this bug. ***
Assignee: brendan → dougt
Status: ASSIGNED → NEW
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
Assignee: dougt → norris
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.
Status: NEW → ASSIGNED
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()
Blocks: 15745
Blocks: 15746
Whiteboard: Fix almost in hand → more work to do
Summary: javascript: URLs aren't working → [DOGFOOD] javascript: URLs aren't working
Marking dogfood.
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.
Assignee: norris → vidur
Status: ASSIGNED → NEW
Checked in my changes. Reassigning to vidur since he wrote the nsLocation code.
Assignee: vidur → nisheeth
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!
Whiteboard: more work to do → [PDT+] more work to do
Blocks: 16950
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.)
Status: NEW → ASSIGNED
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.
(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...)
*** Bug 17343 has been marked as a duplicate of this bug. ***
Blocks: 17432
*** Bug 16802 has been marked as a duplicate of this bug. ***
*** Bug 15267 has been marked as a duplicate of this bug. ***
No longer blocks: 17432
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.
Blocks: 17907
Status: ASSIGNED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] more work to do → [PDT+]
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.
Status: RESOLVED → VERIFIED
Tested with 1999-11-11-09 with Win-95. Working fine, Marking verified.
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
No longer blocks: 11963
No longer blocks: 17907
Keywords: testcase
Summary: [DOGFOOD] javascript: URLs aren't working → javascript: [DOGFOOD] URLs aren't working
Blocks: 8920
*** Bug 7398 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.