23690 - Crash trying to save a link at this web site

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[scalkins]

Saw this in Win build 2000-01-11-09 M13

Steps to repro:
1)Launch Seamonkey. Go to URL http://www.webvan.com
2)On the left pane, under the "Webvan" logo, right mouse click on the link
"Schedule a Delivery" to get a pull down menu.
3)Select "Save Link As" from this menu.

Expected results: You get a "Save As" dialog box.

Actual Results: You will crash.
Notes: You will also crash if trying to save links under the "Shop Now For:"
heading at this site.

Comment 1

[scalkins]

I could not get a talkback report because of a problem with the way talkback is
sending the reports in todays build...but will put one in when it's been
addressed.

Comment 2

[Sean Richardson]

The crash is almost certainly happening because Mozilla is being asked to
save a file that does not exist, because the javascript that would load it
has not been run. Perhaps the error condition of trying to save a file that
does not exist should be trapped regardless of how this bug is fixed, as a
precaution.

The link in question is "javascript:loginfn("SDelivery")", which loads
"http://www20.webvan.com/Auth/Login.asp?url=SDelivery" into the main body
frame. The other links mentioned are also to javascript: URLs.

The question here is, what should Mozilla be expected to do when asked to
save javascript: URLs? Should the javascript be evaluated to try to find
a file that can be saved? In this case, "Open Link in New Windows" on the
context menu does not result in the HTML for the frame being loaded into a new
window. If the javascript *is* evaluated, the "Save Link As..." code needs to
be ready for that evaluation to not result in a saveable file.

Or, should the "Save Link As" item simply not appear on the context menu if the
link is to a javascript: URL (or any other that does not result in a file
transfer)?

Trying the same thing with NN 4.7 on WinNT, the Save As dialog came up with
no filename, and after providing one, no file was saved.

Comment 3

[Sean Richardson]

The crash could also be the result of the javascript being evaluated but not
resulting in anything like a file outside of the context of the frameset,
causing the "Save Link As..." to hurl.

A mysterious
  >X Pos: 104
  >Y Pos: 138
appears on the console just before the crash ... the numbers seem to be right
for the click position within the frame.

The javascript in question is in
http://www17.webvan.com/LeftTb.asp?shopactive= - the URL for the left frame.
I don't know enough about the language to tell if this is standards-compliant
code or not - although it does do the same thing as in NN 4.7 if the link is
clicked on rather than trying to "Save Link As...".

Should this get passed to "DOM Level 1" or "XPApps", or who? I'm stumped.

Comment 4

[leger]

claudius, can you reproduce with latest build?

Comment 5

[saari (gone)]

Yeah, this is defintely a problem with the JS. Looks like a missing check for
null based on the stack.

Don, I think this is yours...

Comment 6

[sairuh (rarely reading bugmail)]

tried checking this out w/y'day's 2000011811 comm bits on NT, but whenever i go
to the above URL, the page is blank. [not checked with today's bits for win as
they're supposedly bad].

crashed on today's 2000011909 linux comm bits, Talkback incident 4143163 (link
below), but it doesn't seem to give much info:

http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=7&cp=1&ck1=
SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=4143163

also crashed with today's mac 2000011909 mozilla bits; will attach stack trace
soon...

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: MacsBug stack trace for crasher

Comment 8

[leger]

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.

Comment 9

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 10

[Colin Slater]

Attachment: Decomposed File to recreate this bug

Comment 11

[Colin Slater]

This is a simple problem. Mozilla Crashed when it stumbled over a javascript
link. It is easy to fix, just put some code in to detect javascript links, and
if it finds one, gray out some menu items.

Comment 12

[don]

Bill, is this fixable for M14 or should we move this out to M15?

Comment 13

[Bill Law]

Certainly "fixable," per some definition of the word, in M14.  I can do what 
[e-mail] suggests without much trouble.  I've some concerns about a 
blanket prohibition against saving javascript: URLs, though.  I'm not sure 
there's not some funky javascript: URLs that might make sense to save.  But I 
can't come up with any off the top of my head so it seems we're better off 
blocking them rather than crashing.

I can't quite wrap my head around the semantics of "saving" a link to a 
javascript URL.  Anybody care to describe that?

BTW, I tried this with IE5 on Win98 and get a message box that tells me 
"Internet Explorer cannot download from the Internet site from 
loginfn("SDelivery").  No such interface supported."

Comment 14

[sairuh (rarely reading bugmail)]

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

Comment 15

[Bill Law]

I've got a fix in my tree.  I'll extract a diff and get a review and then check 
it in.

Comment 16

[sairuh (rarely reading bugmail)]

nominating for beta1...since this didn't make it in for m14. still crashes when
using this morning's opt bits [2000.03.01] on linux (comm), winNT (comm) and mac
(mozilla).

Comment 17

[leger]

don to check out and give us info on PDT call.

Comment 18

[don]

The fix is ready and Bill is testing it today.

Comment 19

[Bill Law]

Attachment: Patch to disable some context menu items for javascript: links

Comment 20

[Phil Peterson]

PDT+

Comment 21

[don]

Updated status whiteboard summary ...

Comment 22

[Doron Rosenberg (IBM)]

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

Comment 23

[Bill Law]

Fix checked in.

Comment 24

[sairuh (rarely reading bugmail)]

Save Link As... no longer in the context menus for such links. verif w/opt comm
bits on linux and mac [2000.03.08.0x]; unable to verif on winNT due to bug
31020.

Comment 25

[sairuh (rarely reading bugmail)]

verif on winNT using 2000.03.08.13 bits.