"View page source" on "xul" error page re-renders error page in view source window, instead of showing source

NEW
Unassigned

Status

()

Core
Document Navigation
13 years ago
4 months ago

People

(Reporter: Biesinger, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

"View page source" on "xul" error page re-renders error page in view source
window, instead of showing source.  since I don'T think we care much about
showing the error page source, we should probably just disable the menuitem...
fyi, it doesn't happen with "view selection source".
Of course -- "view selection source" doesn't need to try to actually get the
source or anything like that.

Comment 3

13 years ago
Testing on Mac OS X, view page source shows the source of the last page (which
may be about:blank) and view selection source shows the source of the error page.

Both should just be disabled.
*** Bug 300627 has been marked as a duplicate of this bug. ***
Created attachment 190311 [details] [diff] [review]
patch to show error page source

this'd show the error page source in view source, but it was vetoed

Comment 6

13 years ago
(In reply to comment #5)
> Created an attachment (id=190311) [edit]
> patch to show error page source
> 
> this'd show the error page source in view source, but it was vetoed

IMO there's nothing wrong with showing the actual source of the error page.. you
can do this in IE too.
The pref "browser.xul.error_pages.enabled" is only checked within
nsDocShell::Create(). Changing it within the current tab seems that it is not
triggered. 

http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#3383
docshell should probably add itself as pref observer
(nsIPrefBranch2::AddObserver) for that pref. note that it should not overwrite
disabling of error pages via SetUseErrorPages(PR_FALSE).
That patch might have been vetoed, but the current behaviour (reopen the error
page with an empty error URI) is stupid.

Comment 10

13 years ago
Strange.. and hard to reproduce, but for some reason on a Network Timeout error
page, it showed the source of the previous page.
*** Bug 311500 has been marked as a duplicate of this bug. ***

Comment 12

12 years ago
*** Bug 303448 has been marked as a duplicate of this bug. ***

Comment 13

12 years ago
Created attachment 207707 [details]
Happy screenshot of source view about: (error page) 

Without comments.

Comment 14

12 years ago
Im not sure that my problem is same, but I do the happy screenshot ( https://bugzilla.mozilla.org/attachment.cgi?id=207707 ).

The most happy think is progress bar in View Source window.

Yes I think tat viewing of source code of error page is stupid (I will not try this anytime) but I think :"That is a nice page. How is writed ???". 
We know what the problem is.  Please stop spamming the bug, ok?  Unless you're planning to post a patch to fix it.
Duplicate of this bug: 393002
cross-posting my comment from bug 397937:

> Bug 273968 must be either invalid or wontfix. If you actually can't reach a
> server, you can't view the source of a page -- so view-source fails, and the
> error page makes sense again. You could view the source of the error page, but
> I don't know what that would be useful for. It would only confuse Web
> developers. Those who are really interested in the Firefox source can find or
> inspect it elsewhere.

Disabling the menu item would be an option, but of course there are other ways to tell Firefox to view the source of a page.

Updated

10 years ago
Depends on: 393002
(In reply to comment #17)
> Disabling the menu item would be an option, but of course there are other ways
> to tell Firefox to view the source of a page.

That would be an option. But than the menu item and the shortcut has to be disabled. Other ways which are not easily reachable for normal users shouldn't be too necessary to fix? Or which possibilities do you have in mind?
(In reply to comment #18)
> Other ways which are not easily reachable for normal users shouldn't
> be too necessary to fix? Or which possibilities do you have in mind?

The "view-source" scheme, which is reasonably popular. But that's not really a problem. I, at least, am fine with the current behavior. Bug 393002 should be fixed though.

Comment 20

10 years ago
Alternatively we could disable error pages in the view source window.
(In reply to comment #20)
> Alternatively we could disable error pages in the view source window.

What do you want to display instead?
OS: Linux → All
QA Contact: adamlock → docshell
Hardware: PC → All
Per bug 431955 steps:


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre] (nightly) (W2Ksp4)

Described behavior,
plus Error in Error Console
{{
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.hostname]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: about:neterror?e=nssBadCert&u=view-source%3Ahttps%3A//www.gmail.com/&c=&d=www.gmail.com%20uses%20an%20invalid%20security%20certificate.%0A%0AThe%20certificate%20is%20only%20valid%20for%20%3Ca%20id%3D%22cert_domain_link%22%20title%3D%22mail.google.com%22%3Email.google.com%3C/a%3E%0A%0A%28Error%20code%3A%20ssl_error_bad_cert_domain%29%0A :: addDomainErrorLink :: line 223"  data: no]
}}


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050202 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

ViewSource window displays an alert dialog
{{
Alert

www.gmail.com:443 uses an invalid security certificate.
The certificate is only valid for <a id="cert_domain_link" title="mail.google.com">mail.google.com</a>

(Error code: ssl_error_bad_cert_domain)
}}
and does not load anything.


SeaMonkey' behavior seems "better",
except for the |<a>| tag, which doesn't make sense in a dialog.

Updated

9 years ago
Duplicate of this bug: 471110
Assignee: cbiesinger → nobody
You need to log in before you can comment on or make changes to this bug.