Closed
Bug 62744
Opened 25 years ago
Closed 24 years ago
Link.protocol throws exception on unknown URL scheme
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla0.9.7
People
(Reporter: nplatis, Assigned: jst)
References
()
Details
(Whiteboard: checklinux)
Attachments
(4 files)
|
3.18 KB,
text/html
|
Details | |
|
686 bytes,
text/html
|
Details | |
|
1.73 KB,
patch
|
Details | Diff | Splinter Review | |
|
5.02 KB,
patch
|
fabian
:
review+
rpotts
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001212
BuildID: 2000121204
For some images in the above URL, selecting "Save Image As..." does not display
the "Save File" dialog.
Reproducible: Always
Steps to Reproduce:
Go to the above URL.
Try saving the first and second images of the page -- everything works fine.
Then try saving the next three images of the page -- the "Save File" dialog does
not appear at all.
|
||
Comment 1•25 years ago
|
||
Same here. 2000121220 trunk WinNT4 SP6a
Save dialog opens for the first two images not for the rest.
|
|
||
Comment 2•25 years ago
|
||
Looking at the source, I found that the HTML is not at all standard HTML : no
<html></html>, no <head></head>, <h1> before <body>; no </body>, ...
I ran HTML Tidy on this file and with the output HTML, I have no problem to save
all the images.
So it seems the (very) bad HTML is the cause.
|
||
Comment 3•25 years ago
|
||
For the images in question _none_ of the context menu options seem to work.
When the context menu is brought up, the console shows the following error message:
JavaScript error:
line 0: uncaught exception: [Exception... "<no message>" code: "-2142568438"
nsresult: "0x804b000a (<unknown>)" location:
"chrome://communicator/content/nsContextMenu.js Line: 357"]
JavaScript error:
line 0: contextMenu has no properties
When an option is selected from the menu, the console shows:
JavaScript error:
line 0: contextMenu has no properties
Another interesting detail. If one opens the page in question in a new window
and right-clicks on one of the "bad" images, the context menu includes all the
image options as well as all the link options and all the frame options. If one
then right-clicks on one of the "good" images and then goes back to the "bad"
one the context menu looks the same as it did for the "good" image.
Looks like the context menu is not being initialized correctly...
|
||
Updated•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: correctness,
regression
OS: Windows 98 → All
Hardware: PC → All
|
|
||
Comment 4•25 years ago
|
||
confirming on linux 2000.12.11.12 and mac 2000.12.13.08. i can save images [via
context menu] *until* i get to the 3rd image on the page --at which point, Save
Image... is no longer in the context menu *and* selecting Save As... results in
the error Boris mentions above.
bill/mscott, any idea what's going on here?
I'm reassigning this to myself. It is a context menu problem. The bogus HTML
causes the context menu content analysis to barf (or, causes the underlying DOM
to be bogus).
The exception occurs on a line referencing "link.protocol" which, by rights,
shouldn't throw a JS exception (I don't think). Either the object has the
property or it doesn't.
The fix is to add appropriate defensive programming to avoid/handle the
exception. Or, to fix the underlying problem which causes the exception (rather
than simply a null link.protocol property value).
Assignee: ben → law
|
||
Updated•24 years ago
|
Whiteboard: re-check dups when this is fixed
|
||
Comment 9•24 years ago
|
||
This is a DOM issue really, as law notes. In Nav4.x, getting the property
Link.protocol for an HREF with an unknown or bogus scheme would simply return
"file:" [which is correct, since any character sequence might be a file
reference depending on the set of legal characters for a given filesystem].
But in seamonkey/mojo, an exception is thrown for unknown or bogus schemes
(and actually is even thrown for well known schemes gopher: and telnet:.
Oh, how soon they forget :-]). I'll attach a test case.
Assignee: law → jst
Summary: "Save Image As..." fails → "Save Image As..." fails. DOM throws exception on unknown URL scheme
|
|
||
Comment 10•24 years ago
|
||
|
|
||
Comment 11•24 years ago
|
||
... actually, maybe it isn't DOM per se, since I think it is just forwarding
the request onto necko url routines.
|
Assignee | |
Comment 12•24 years ago
|
||
Removing regression keyword since I don't think this is a regression (put it
back if you disagree). The original URL doesn't seem to exist any more, could
someone update the URL field if the page moved or is the page no more?
Keywords: regression
|
|
||
Comment 13•24 years ago
|
||
You can use the attached testcase and try the link with protocol 'xxx://',
instead of the original URL (which does seem to have gone missing).
I stepped through this for a while, and The problem happens in
nsIOService::GetProtocolHandler in netwerk\base\src\nsIOService.cpp, on this
stack:
nsIOService::GetProtocolHandler(nsIOService * const 0x00b91d98, const char *
0x037f4828, nsIProtocolHandler * * 0x0012d730) line 202
nsIOService::NewURI(nsIOService * const 0x0012d730, const char * 0x02605398,
nsIURI * 0x00000000, nsIURI * * 0x0012d8cc, nsIProtocolHandler * * 0x00000000)
line 264
nsIOService::NewURI(nsIOService * const 0x00b91d98, const char * 0x02605398,
nsIURI * 0x00000000, nsIURI * * 0x0012d8cc) line 279
NS_NewURI(nsIURI * * 0x0012d8cc, const char * 0x02605398, nsIURI * 0x00000000,
nsIIOService * 0x00000000) line 74 + 15 bytes
nsHTMLAnchorElement::GetProtocol(nsHTMLAnchorElement * const 0x025560f4,
basic_nsAWritableString<unsigned short> & {...}) line 438 + 55 bytes
GetHTMLAnchorElementProperty(JSContext * 0x00cff148, JSObject * 0x00db88e0,
long 39149812, long * 0x0012db1c) line 244 + 16 bytes
In the process of creating a new nsIURI (for simple parsing methods I
assume), in GetProtocolHandler(), if the scheme is not one of a
well-known (or previously cached) set of schemes, then this winds up trying to
get the service for contractid "@mozilla.org/network/protocol;1?name=xxx",
and of course failing. It seems there needs to be a way to get at some of
nsIURI's utility methods, without getting a full-blown instance.
|
|
Assignee | |
Comment 14•24 years ago
|
||
Over to Necko to get their opinion on this.
Assignee: jst → neeti
Component: XP Apps: GUI Features → Networking
QA Contact: sairuh → tever
|
|
||
Comment 15•24 years ago
|
||
*** Bug 68310 has been marked as a duplicate of this bug. ***
|
Reporter | |
Comment 16•24 years ago
|
||
The original page is up again, at a different URL. Updating URL accordingly...
|
||
Comment 17•24 years ago
|
||
Gagan,
We are returning an NS_ERROR_UNKNOWN_PROTOCOL from
nsExternalProtocolHandler::NewURI(..) When it is called from
nsHTMLAnchorElement::GetProtocol(..).
In GetHTMLAnchorElementProperty(..), GetProtocol(..) fails, resulting in the
error message mentioned above. How should necko deal with this?
Here is the stack trace
nsExternalProtocolHandler::NewURI(nsExternalProtocolHandler * const 0x04135a20,
const char *
0x04e46570, nsIURI * 0x00000000, nsIURI * * 0x0012ce7c) line 307
nsIOService::NewURI(const char * 0x04e46570, nsIURI * 0x00000000, nsIURI * *
0x0012ce7c,
nsIProtocolHandler * * 0x00000000) line 288 + 35 bytes
nsIOService::NewURI(nsIOService * const 0x013a48d0, const char * 0x04e46570,
nsIURI *
0x00000000, nsIURI * * 0x0012ce7c) line 296
NS_NewURI(nsIURI * * 0x0012ce7c, const char * 0x04e46570, nsIURI * 0x00000000,
nsIIOService * 0x013a48d0) line 77 + 24 bytes
NS_NewURI(nsIURI * * 0x0012ce7c, const nsAString & {...}, nsIURI * 0x00000000,
nsIIOService *
0x00000000) line 89 + 21 bytes
nsHTMLAnchorElement::GetProtocol(nsHTMLAnchorElement * const 0x04e02060,
nsAString & {...})
line 437 + 43 bytes
GetHTMLAnchorElementProperty(JSContext * 0x041045d0, JSObject * 0x0262a390, long
-25, long
* 0x0012e654) line 244 + 25 bytes
js_GetProperty(JSContext * 0x041045d0, JSObject * 0x0262a390, long 65622768,
long *
0x0012e654) line 2255 + 149 bytes
js_Interpret(JSContext * 0x041045d0, long * 0x0012e80c) line 2540 + 1998 bytes
js_Invoke(JSContext * 0x041045d0, unsigned int 1, unsigned int 2) line 830 + 13
bytes
js_InternalInvoke(JSContext * 0x041045d0, JSObject * 0x0262a150, long 40018536,
unsigned int 0,
unsigned int 1, long * 0x0012e9a4, long * 0x0012e934) line 902 + 20 bytes
JS_CallFunctionValue(JSContext * 0x041045d0, JSObject * 0x0262a150, long
40018536, unsigned int
1, long * 0x0012e9a4, long * 0x0012e934) line 3334 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x04104780, void * 0x0262a150,
void *
0x0262a268, unsigned int 1, void * 0x0012e9a4, int * 0x0012e9a0, int 0) line 940
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04e462c4) line 154 + 64 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x04e01bf0,
nsIDOMEvent *
0x04e462c4, nsIDOMEventTarget * 0x04e01e04, unsigned int 4, unsigned int 7) line
1035 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x04e3e030, nsEvent *
0x0012f3a8,
nsIDOMEvent * * 0x0012f0c0, nsIDOMEventTarget * 0x04e01e04, unsigned int 7,
nsEventStatus *
0x0012f734) line 1201 + 39 bytes
nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x04e05ac0,
nsIPresContext *
0x04e3e030, nsEvent * 0x0012f3a8, nsIDOMEvent * * 0x0012f0c0, unsigned int 1,
nsEventStatus *
0x0012f734) line 1506
nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x04e05ac0,
nsIPresContext *
0x04e3e030, nsEvent * 0x0012f3a8, nsIDOMEvent * * 0x00000000, unsigned int 1,
nsEventStatus *
0x0012f734) line 1080 + 29 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f3a8, nsIView * 0x00000000,
unsigned int 1,
nsEventStatus * 0x0012f734) line 5498 + 47 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x04141220, nsEvent *
0x0012f3a8, nsIFrame *
0x0263a684, nsIContent * 0x04e05ac0, unsigned int 1, nsEventStatus * 0x0012f734)
line 5471 + 22
bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const
0x047dd3a0,
nsIPresContext * 0x04e3e030, nsMouseEvent * 0x0012f840, nsEventStatus *
0x0012f734) line 2340 +
61 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x047dd3a8,
nsIPresContext *
0x04e3e030, nsEvent * 0x0012f840, nsIFrame * 0x0263a684, nsEventStatus *
0x0012f734, nsIView *
0x047fc770) line 1439 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f840, nsIView * 0x047fc770,
unsigned int 1,
nsEventStatus * 0x0012f734) line 5518 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x04141224, nsIView * 0x047fc770,
nsGUIEvent *
0x0012f840, nsEventStatus * 0x0012f734, int 0, int & 1) line 5425 + 25 bytes
nsView::HandleEvent(nsView * const 0x047fc770, nsGUIEvent * 0x0012f840, unsigned
int 8,
nsEventStatus * 0x0012f734, int 0, int & 1) line 377
nsView::HandleEvent(nsView * const 0x047febf0, nsGUIEvent * 0x0012f840, unsigned
int 8,
nsEventStatus * 0x0012f734, int 0, int & 1) line 350
nsView::HandleEvent(nsView * const 0x04145c60, nsGUIEvent * 0x0012f840, unsigned
int 28,
nsEventStatus * 0x0012f734, int 1, int & 1) line 350
nsViewManager::DispatchEvent(nsViewManager * const 0x0413bb40, nsGUIEvent *
0x0012f840,
nsEventStatus * 0x0012f734) line 2055
HandleEvent(nsGUIEvent * 0x0012f840) line 68
nsWindow::DispatchEvent(nsWindow * const 0x047feab4, nsGUIEvent * 0x0012f840,
nsEventStatus &
nsEventStatus_eIgnore) line 704 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f840) line 725
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4028 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
4273
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 23593336, long *
0x0012fc10) line
3009 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00f3090e, unsigned int 514, unsigned int 0, long
23593336)
line 959 + 27 bytes
USER32! 77e7124c()
|
||
Comment 18•24 years ago
|
||
This works for me (linux and windows). This is also a relatively older bug.
Could the reporter verify this with the latest build?
|
|
||
Comment 19•24 years ago
|
||
Try the testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23316
The thing is, if a full blown component supporting the 'xxx://' protocol does
not exist, then we can't parse any part of a 'xxx://foo/bar.html' URL. It
should be possible to deal with protocol schemes without having a full
implementation for that scheme. However, this may not be a pressing issue
in the near term, since we handle the most widely used schemes.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Comment 20•24 years ago
|
||
Moving this to mozilla0.9.2, sinc I think this bug depends on bug 73845
http://bugzilla.mozilla.org/show_bug.cgi?id=73845
Target Milestone: mozilla0.9.1 → mozilla0.9.2
|
||
Comment 22•24 years ago
|
||
I played with this recently.... I should take a look see.
Assignee: neeti → dougt
Status: REOPENED → NEW
|
||
Comment 23•24 years ago
|
||
-qawanted - I got this for now.
Where are we with this? Is this a networking problem, or an XP menu problem?
Bug 46537 shows that location bar has problems w/ handling all the right
situations.
Keywords: qawanted
|
|
||
Comment 24•24 years ago
|
||
bbaetz patched nsContextMenu.js to not barf anymore when bringing up a context
menu for a link with an unknown protocol scheme. However, the root problem
still exists and I'll attach a simple test case.
We should be able to ask any URL for its scheme without necessarily having
a handler for the protocol. And we really shouldn't need to created a URL
handler object just to ask that question (currently we need to be able to
create a "@mozilla.org/network/protocol;1?name=xxx" just to ask it to tell
us the scheme).
Summary: "Save Image As..." fails. DOM throws exception on unknown URL scheme → Link.protocol throws exception on unknown URL scheme
|
|
||
Comment 25•24 years ago
|
||
|
|
||
Comment 26•24 years ago
|
||
Hmm, curiously Nav4.x will report the scheme of the parent document as the
scheme of a link with an unknown/bogus protocol. (e.g., 'http' is loaded
by http, 'file' if loaded from disk). That's not ideal either.
|
||
Comment 27•24 years ago
|
||
jrgm - right, my patch was, IIRC, just a sanity check. There are issues with
just trying to parse it anyway, IIRC. dougt?
|
|
||
Comment 28•24 years ago
|
||
"unknown" you mean "unregistered" right? not, like unknown like just a URI in
the HREF? Thanks in advance...
|
|
||
Comment 29•24 years ago
|
||
I don't get the second half of your sentence. Anyways, I mean 'unknown'
in this sense.
Suppose some savvy dude invents the 'benc://' protocol. In the
current implementation of mozilla, given a string (URL) like
"benc://foopy.net/cool.stuff", then the only way that we can find
out what scheme that URL is using, is to already have an implementation
of the 'benc://' protocol.
There should be static methods that simply expose the ability to parse
a URL and extract the sub-parts without needing to actually create an
instance of that URI's handler.
|
|
||
Comment 30•24 years ago
|
||
Okay, I think I am starting to understand. I am not sure why you would need to
parse the URI of an unknown scheme. Isn't that hard if you don't recognize the
protocol because the punctuation is inconsisent? (":" vs. "://" ?)
So there is a fixed list of schemes that we handle, and then everything else
should return an error right? Or should we ask the OS if it has a handler? That
is the part I am most worried about now.
|
|
||
Comment 31•24 years ago
|
||
nsHTMLAnchorElement::GetProtocol, i think is busted. There is no real need to
call NS_NewURI.
something like this would work better: (note I have not built nor tested this)
NS_IMETHODIMP
nsHTMLAnchorElement::GetProtocol(nsAWritableString& aProtocol)
{
nsAutoString href;
nsCOMPtr<nsIURI> url;
nsresult result = NS_OK;
result = GetHref(href);
if (NS_OK == result) {
char* protocol = nsnull;
if (!nsHTMLUtils::IOService)
return NS_ERROR_FAILURE;
result = nsHTMLUtils::IOService->ExtractScheme(nsnull, nsnull, nsnull,
&protocol);
if (NS_FAILED(result)) {
// set the protocol to http since it is the mostlikely protocol to be used.
protocol = PL_strndup("http", 4);
}
aProtocol.Assign(NS_ConvertASCIItoUCS2(protocol));
aProtocol.Append(PRUnichar(':'));
nsCRT::free(protocol);
}
return result;
}
Jonny, who should own this?
Assignee: dougt → jst
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
|
Assignee | |
Comment 32•24 years ago
|
||
Pushing to mozilla0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
|
|
Assignee | |
Updated•24 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
|
|
Assignee | |
Comment 33•24 years ago
|
||
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
|
|
Assignee | |
Comment 34•24 years ago
|
||
|
|
Assignee | |
Comment 35•24 years ago
|
||
|
||
Comment 36•24 years ago
|
||
Comment on attachment 59835 [details] [diff] [review]
Maybe this will be a bit closer to what's expected.
What about modifying nsLocation::GetProtocol as well? Code looks good apart
from that.
|
|
Assignee | |
Comment 37•24 years ago
|
||
I don't think we'll need to touch the nsLocation code since nsLocation will
never contain an URL with an unknown protocol, if the protocol is unknown, we
can't load the page, and the URL will never show up in nsLocation.
|
|
Assignee | |
Comment 38•24 years ago
|
||
Rick, could you sr the latest patch in this bug please?
Status: NEW → ASSIGNED
Whiteboard: re-check dups when this is fixed → [HAVE FIX] re-check dups when this is fixed
|
|
||
Comment 39•24 years ago
|
||
Comment on attachment 59835 [details] [diff] [review]
Maybe this will be a bit closer to what's expected.
r=fabian
Attachment #59835 -
Flags: review+
|
||
Updated•24 years ago
|
Attachment #59835 -
Flags: superreview+
|
|
||
Comment 40•24 years ago
|
||
Comment on attachment 59835 [details] [diff] [review]
Maybe this will be a bit closer to what's expected.
sr=rpotts@netscape.com
|
|
Assignee | |
Comment 41•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
|
|
||
Comment 42•23 years ago
|
||
VERIFIED: Mozilla 1.3a, Win 98.
I'll get the other plats tomorrow.
Whiteboard: [HAVE FIX] re-check dups when this is fixed → [HAVE FIX] checkmac checklinux
|
|
||
Comment 43•17 years ago
|
||
VERIFIED: Firefox 3, Mac OS X 10.5...
Whiteboard: [HAVE FIX] checkmac checklinux → checklinux
You need to log in
before you can comment on or make changes to this bug.
Description
•