347047 - External source viewer does not work for pages that ask not to be cached

Status: NEW

(Toolkit :: View Source, defect)

Description

[Jez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

In bug #172817, Jason Barnabe et al very kindly added functionality to Firefox to allow an external program to be used as a source viewer, rather than always using the internal viewer.  It involves setting 2 prefs, view_source.editor.external and view_source.editor.path, to tell FF that the user wants to use an external source viewer and give the location to the viewer.

I've been using these extensively and they've worked fine on most pages, but I've come across some pages where they don't.

http://forums.cpanel.net/

For these pages, Firefox re-downloads the source and always displays it in the internal viewer when you try to view source.

Those pages have the following set, which I think is very likely to be the cause of the behaviour:
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1" />
<meta http-equiv="Cache-Control" content="no-cache" />

Not sure which causes it, but presumably Firefox should indeed re-download the content (actually a choice of whether or not would be nice but I guess that's a separate RFE), and display it in the external viewer, having saved a temp file.  I'm guessing it's currently not saving the temp file as it's not caching it.

Reproducible: Always

Comment 1

[Simon Bünzli]

Error: Component returned failure code: 0x80460003 (NS_ERROR_LOSS_OF_SIGNIFICANT_DATA) [nsIConverterOutputStream.writeString]
Source file: chrome://global/content/viewSourceUtils.js
Line: 180

Which originates at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/intl/uconv/src/nsConverterOutputStream.cpp&rev=1.3&mark=108-114#86 A bug to that extent might already have been filed somewhere else. Confirming anyway.

For Firefox 2, we should at least have viewSourceUtils.js Components.utils.reportError the exceptions which lead to the falling back to the internal handler.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Probably the right fix is to always encode to UTF8 or something, not to the page charset.  In this case, the page probably contains chars that can't be expressed in ISO-8859-1.

Comment 3

[Simon Bünzli]

Although claiming to be ISO-8859-1, the page rather seems to be encoded in Cp1252. Not sure whether the better alternative is to always convert to UTF-8 or to rather convert to the platforms default encoding and have undisplayable characters replaced by <?>. The latter would yield better results with non-UTF-8 capable editors (the former would at least have to include the BOM, otherwise I'm convinced that a whole lot of editors would break under Windows).

Comment 4

[fraster]

Also to me have problem with edito and page as http://forums.cpanel.net/