Crash trying to save a link at this web site

VERIFIED FIXED in M14

Status

()

Core
XUL
P1
critical
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: scalkins, Assigned: Bill Law)

Tracking

({crash})

Trunk
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] UPDATE! fix in hand, waiting on review and approval, URL)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Priority: P3 → P1
(Reporter)

Comment 1

19 years ago
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

19 years ago
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

19 years ago
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.

Updated

19 years ago
Assignee: nobody → saari
Component: Browser-General → XPMenus
QA Contact: nobody → sairuh

Comment 4

19 years ago
claudius, can you reproduce with latest build?

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M14

Updated

19 years ago
Assignee: saari → don
Status: ASSIGNED → NEW

Comment 5

19 years ago
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...
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...
Created attachment 4364 [details]
MacsBug stack trace for crasher

Comment 8

19 years ago
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus

Comment 9

19 years ago
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: [MAKINGTEST] cslater@wcnet.org

Comment 10

19 years ago
Created attachment 4705 [details]
Decomposed File to recreate this bug

Updated

19 years ago
Whiteboard: [MAKINGTEST] cslater@wcnet.org → [TESTCASE] cslater@wcnet.org

Comment 11

19 years ago
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

19 years ago
Bill, is this fixable for M14 or should we move this out to M15?
Assignee: don → law
Status: ASSIGNED → NEW
(Assignee)

Comment 13

19 years ago
Certainly "fixable," per some definition of the word, in M14.  I can do what 
cslater@wcnet.org 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."
Status: NEW → ASSIGNED
*** Bug 26969 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

19 years ago
I've got a fix in my tree.  I'll extract a diff and get a review and then check 
it in.
Whiteboard: [TESTCASE] cslater@wcnet.org → [TESTCASE] cslater@wcnet.org [got fix, need approval and checkin)
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).
Keywords: beta1

Comment 17

19 years ago
don to check out and give us info on PDT call.
Whiteboard: [TESTCASE] cslater@wcnet.org [got fix, need approval and checkin) → [NEED INF0][TESTCASE] cslater@wcnet.org [got fix, need approval and checkin)

Comment 18

19 years ago
The fix is ready and Bill is testing it today.
Whiteboard: [NEED INF0][TESTCASE] cslater@wcnet.org [got fix, need approval and checkin) → [TESTCASE] cslater@wcnet.org (got fix, need approval and checkin)
(Assignee)

Comment 19

19 years ago
Created attachment 6006 [details] [diff] [review]
Patch to disable some context menu items for javascript: links

Comment 20

19 years ago
PDT+
Whiteboard: [TESTCASE] cslater@wcnet.org (got fix, need approval and checkin) → [PDT+] w/b minus on 3/3 [TESTCASE] cslater@wcnet.org (got fix, need approval and checkin)

Comment 21

19 years ago
Updated status whiteboard summary ...
Whiteboard: [PDT+] w/b minus on 3/3 [TESTCASE] cslater@wcnet.org (got fix, need approval and checkin) → [PDT+] UPDATE! fix in hand, waiting on review and approval
*** Bug 30446 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

19 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
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.
Depends on: 31020
verif on winNT using 2000.03.08.13 bits.
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.