Closed
Bug 1646
Opened 26 years ago
Closed 25 years ago
javascript: [DOGFOOD] URLs aren't working
Categories
(Core :: Networking, defect, P2)
Core
Networking
Tracking
()
VERIFIED
FIXED
M11
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)".
Comment 1•26 years ago
|
||
batch-reassigning all Garrett Blythe bugs to Don Melton
Re-assigned to vidur@netscape.com.
Vidur, since this isn't an xpapps issue, do you who should get this bug?
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 3•26 years ago
|
||
Known problem with javascript: URLs after Warren's URL parsing checkin.
Updated•26 years ago
|
Component: Windows FE → JavaScript
Product: MozillaClassic → Browser
Comment 6•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA contact re-assigned according to the product areas we're currently working
on.
Updated•26 years ago
|
Summary: Links to pages defined using JavaScript aren't working → javascript: URLs aren't working
Target Milestone: M4 → M5
Updated•26 years ago
|
Target Milestone: M5 → M6
Comment 10•26 years ago
|
||
I'm waiting for the new netlib before I rewrite javascript: processing.
Comment 11•26 years ago
|
||
*** Bug 1919 has been marked as a duplicate of this bug. ***
Comment 12•26 years ago
|
||
*** Bug 5540 has been marked as a duplicate of this bug. ***
Comment 13•26 years ago
|
||
*** Bug 5412 has been marked as a duplicate of this bug. ***
Comment 14•26 years ago
|
||
*** Bug 5840 has been marked as a duplicate of this bug. ***
Comment 15•26 years ago
|
||
*** Bug 6222 has been marked as a duplicate of this bug. ***
Comment 16•26 years ago
|
||
*** Bug 5410 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Summary: javascript: URLs aren't working → [BLOCKING WALLET] javascript: URLs aren't working
Updated•26 years ago
|
Summary: [BLOCKING WALLET] javascript: URLs aren't working → javascript: URLs aren't working
Comment 17•26 years ago
|
||
Wallet code does not need to use javascript: URLs. It should be updated to use
onclick handlers instead.
Updated•26 years ago
|
Assignee: vidur → brendan
Status: ASSIGNED → NEW
Comment 18•26 years ago
|
||
Brendan is going to help out with javascript: URLs.
Updated•26 years ago
|
Summary: javascript: URLs aren't working → [BLOCKING WALLET] javascript: URLs aren't working
Comment 19•26 years ago
|
||
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•26 years ago
|
||
*** Bug 6587 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
Comment 21•26 years ago
|
||
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•26 years ago
|
||
Moving to DOM Level 0 component. Move to DOM Level 1 if that is more correct.
Updated•26 years ago
|
Component: DOM Level 0 → Networking Library
Comment 23•26 years ago
|
||
This is more netlib than DOM.
/be
Comment 24•26 years ago
|
||
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•26 years ago
|
||
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•26 years ago
|
||
*** Bug 7506 has been marked as a duplicate of this bug. ***
Comment 27•26 years ago
|
||
*** Bug 8789 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Target Milestone: M8 → M9
Comment 28•26 years ago
|
||
Need Necko, so M9.
/be
Comment 29•26 years ago
|
||
See bug 9009
Comment 30•26 years ago
|
||
Opps, nevermind. I didn't realized that javascript: was already in the protocol
hash table pointing at the nsHttpURLFactory... Hmmm...
Comment 31•26 years ago
|
||
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•26 years ago
|
||
*** Bug 10795 has been marked as a duplicate of this bug. ***
Comment 33•26 years ago
|
||
*** Bug 6164 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Summary: [BLOCKING WALLET] javascript: URLs aren't working → [Fix almost in hand] javascript: URLs aren't working
Comment 34•26 years ago
|
||
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
Updated•26 years ago
|
Summary: [Fix almost in hand] javascript: URLs aren't working → javascript: URLs aren't working
Whiteboard: Fix almost in hand
Comment 35•26 years ago
|
||
Is this checked in to M9 branch?
Comment 36•26 years ago
|
||
Moving to Resolved/Fixed per brendan mail to me 08/23 that fix was checked into
M9 branch.
Comment 37•26 years ago
|
||
*** Bug 7547 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Updated•26 years ago
|
Resolution: FIXED → ---
Comment 38•26 years ago
|
||
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•26 years ago
|
||
M9 is leaving the station...moving to M10
Reporter | ||
Comment 40•26 years ago
|
||
My test results were the same as desale's.
Updated•26 years ago
|
Status: REOPENED → ASSIGNED
Comment 41•26 years ago
|
||
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•25 years ago
|
||
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.
Comment 43•25 years ago
|
||
*** Bug 3388 has been marked as a duplicate of this bug. ***
Comment 44•25 years ago
|
||
*** Bug 14978 has been marked as a duplicate of this bug. ***
Comment 45•25 years ago
|
||
*** Bug 15908 has been marked as a duplicate of this bug. ***
Comment 46•25 years ago
|
||
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•25 years ago
|
||
*** Bug 15632 has been marked as a duplicate of this bug. ***
Comment 48•25 years ago
|
||
*** Bug 16102 has been marked as a duplicate of this bug. ***
Comment 49•25 years ago
|
||
*** Bug 16451 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Severity: normal → critical
Comment 50•25 years ago
|
||
javascript: URLs are now crashing on all platforms, raising to critical.
See bug 16451 for stack dumps.
Comment 51•25 years ago
|
||
*** Bug 16387 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Assignee: brendan → dougt
Status: ASSIGNED → NEW
Comment 52•25 years ago
|
||
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
Updated•25 years ago
|
Assignee: dougt → norris
Comment 53•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 54•25 years ago
|
||
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()
Updated•25 years ago
|
Whiteboard: Fix almost in hand → more work to do
Updated•25 years ago
|
Summary: javascript: URLs aren't working → [DOGFOOD] javascript: URLs aren't working
Comment 55•25 years ago
|
||
Marking dogfood.
Comment 56•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: norris → vidur
Status: ASSIGNED → NEW
Comment 57•25 years ago
|
||
Checked in my changes.
Reassigning to vidur since he wrote the nsLocation code.
Assignee | ||
Updated•25 years ago
|
Assignee: vidur → nisheeth
Assignee | ||
Comment 58•25 years ago
|
||
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•25 years ago
|
||
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.)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 60•25 years ago
|
||
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•25 years ago
|
||
(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•25 years ago
|
||
*** Bug 17343 has been marked as a duplicate of this bug. ***
Comment 63•25 years ago
|
||
*** Bug 16802 has been marked as a duplicate of this bug. ***
Comment 64•25 years ago
|
||
*** Bug 15267 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 65•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] more work to do → [PDT+]
Assignee | ||
Comment 66•25 years ago
|
||
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.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 67•25 years ago
|
||
Tested with 1999-11-11-09 with Win-95. Working fine, Marking verified.
Comment 68•25 years ago
|
||
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Summary: [DOGFOOD] javascript: URLs aren't working → javascript: [DOGFOOD] URLs aren't working
Comment 69•22 years ago
|
||
*** 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.
Description
•