User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) Gecko/20070725 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20070725 Firefox/220.127.116.11 When I try to access a server that doens't exist, I get a message saying "Firefox can't find the server at www.somedomainthatdoesntexists.com.". If I try to view the source of this page, I get the same message, but without the server name. This also occurs if I try to access the source in the mail browser window, like visiting "view-source:http://www.somedomainthatdoesntexists.com" Reproducible: Always Steps to Reproduce: 1. Visit a server that doesn't exists 2. Try to view the source or 1. Visit the server with the "view-source:" prefix. Actual Results: The following message is displayed: "Firefox can't find the server at ." Expected Results: The following message should be displayed, as is so on a normal request: "Firefox can't find the server at www.somedomainthatdoesntexists.com."
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 273968
This is not a duplicate of bug 273968. Bug 273968 could very well be invalid, but this one should be fixed regardless. That is, the host should not be empty.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Severity: trivial → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Hardware: PC → All
Component: View Source → Embedding: Docshell
Product: Firefox → Core
QA Contact: view.source → docshell
Version: unspecified → Trunk
Issue here is probably that the host of a view-source URI is empty... Maybe whatever code is involved should be looking at the innermost URI?
biesi, thoughts on comment 3?
or perhaps view-source URIs should return the host of their inner URI
They're an nsSimpleNestedURI. I suppose we could subclass that and just override GetHost....
Wouldn't it make sense for SimpleNestedURI in general to forward GetHost to the inner URI?
I guess we could do that. But then jar: URIs would have the same issue, etc. We could specify that a nested URI must forward certain nsIURI things to the underlying URI. But which ones? It seems that any code that cares about which uri is "really" involved (e.g. the security code) should look at the inner URI.
ok, you're probably right the code in question is this one, I think: http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#2896 (other places in that function too)
Whiteboard: [good first bug]
The patch uses GetInnermostURI because that would work better in the case of nested URIs although GetInnerURI should work in most cases.
Comment on attachment 292022 [details] [diff] [review] patch v1: fixes mentioned problem I think you want to use NS_GetInnermostURI here instead of largely duplicating it.
Attachment #292022 - Flags: superreview?(bzbarsky) → superreview-
Comment on attachment 292031 [details] [diff] [review] patch v2: address issue raised by super-review You don't need the QI. Just call the function and use the URI it returns.
Attachment #292031 - Flags: superreview?(bzbarsky) → superreview-
Sorry, should have taken a look at the implementation of NS_GetInnermostURI first.
Comment on attachment 292088 [details] [diff] [review] patch v3: remove unnecessary QueryInterface Excellent!
Attachment #292088 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 292088 [details] [diff] [review] patch v3: remove unnecessary QueryInterface Request approval for 1.9
Attachment #292088 - Flags: approval1.9?
Comment on attachment 292088 [details] [diff] [review] patch v3: remove unnecessary QueryInterface a=endgame drivers
Attachment #292088 - Flags: approval1.9? → approval1.9+
Checking in docshell/base/nsDocShell.cpp; /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v <-- nsDocShell.cpp new revision: 1.876; previous revision: 1.875 done
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
You need to log in before you can comment on or make changes to this bug.