187611 - Cannot view source when viewing XSLT translated XML documents

Status: VERIFIED FIXED

(Core :: XSLT, defect)

Description

[Taral]

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Build Identifier: Mozilla/5.0 (X11; U; AIX 0007099F4C00; en-US; rv:1.2.1) Gecko/20021209

When an XSLT translated XML document is loaded, the View Source function is
grayed out. It would be useful to at least see the XML that was loaded, even if
the XSL is not visible.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

works for me on Win98.

Are you by any chance switching between tabs in some way to trigger this? Please
provide steps to reproduce.

Comment 2

[Taral]

Okay, got steps.

1. Open a document.
2. Open a new tab.
3. Open the XML doc in that tab.
4. Switch tabs.
5. Switch back.

View source is now unavailable. Tested broken in 1.2.1 and 1.3a releases.

Comment 3

[Taral]

Correction: Only checked 1.2.1.

Comment 4

[Axel Hecht]

this is one of the symptoms of the missing mimetype of the result document.
We have a disabled menu for alternative stylesheets, too.
This seems to be triggered only if the view tries to reevaluate whether the doc
is an "image" doc or not. IIRC I tracked this down to a mimetype test of the 
result document.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There is no way to set the contenttype other then through
nsIDocument::StartDocumentLoad and I don't think we want to call that. (Right?)

It would be easy to add a nsIDocument::SetContentType, but it feels kind'a wierd
to have ::GetContentType sitting on nsIDOMNSDocument but ::SetContentType
sitting on nsIDocument.

We could also add another argument to nsIDocument::Reset, but it seems wrong to
have separate arguments for nsIChannel and content-type, since an nsIChannel
contains a content-type.

Yet another option is to let nsIDocument::Reset get the content-type from the
channel and use that. Since nsIChannel.contentType is setable this would be a
usable solution for us. The only problem with this solution is that we have to
check all callers of nsIDocument::Reset so that we don't suddenly set the
mimetype of a document where we shouldn't.

peterv, what does the DOM guru think?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

jst suggested to put both GetContentType and SetContentType on nsIDocument. As
long as it keeps the same signature as the version in nsIDOMNSDocument the
nameclash should be no problem. This sounds like the simplest solution to me.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch to fix

This implements nsIDocument::GetContentType and nsIDocument::SetContentType and
uses that to set the contenttype of the result document.

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 110873 [details] [diff] [review]
patch to fix

Would we want to add code in the content type setter that asserts if someone
tries to do something silly like set the content type when it's already set, or
set it to something that it can't be (i.e. non-XUL mime type in a XUL
document)?

- IOW, in nsDocument::SetContentType():

+{
+  mContentType = aContentType;

Assert if !mContentType.IsEmpty() and if mContentType != aContentType?

- In content/base/src/nsDocument.h (and also in nsXULDocument.h):

+  //NS_IMETHOD GetContentType(nsAString& aContentType);
+  //Already declared in nsIDOMNSDocument

Add spaces after leading double slashes.

sr=jst

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: added some assertions

fixes comments from jst

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 110906 [details] [diff] [review]
added some assertions

carrying over sr=jst

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

fix checked in. Thanks for reviews

Comment 12

[Axel Hecht]

mass verifying