294634 - Bugzilla is showing only CSS part of an attachment (source XML/SVG/Style)

Status: RESOLVED INVALID

(Bugzilla :: Attachments & Requests, defect)

Description

[Heinz Kohl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

See error message #288165 .. 
    [Bug 288165] SVG path: marker-start/-end (auto orient): wrong direction
 
see e.g. attachment #1183021

The complete XML file is to be seen only with 
   "Edit" Attachment, 
   "Edit As Comment"

Reproducible: Always

Steps to Reproduce:
1.call Bug 288165
2.edit Attachment #1183021 (showing only the css part!!)
3."Edit As Comment" will show up the complete XML file 

Actual Results:  
No working on this error message, because the maintainer was seeing only a
strange detail of the error message

Expected Results:  
Correct text, following by the usual error correction process

For a progress with error message 288165, please inform the maintainer about
this situation

Comment 1

[Marc Schumann [:Wurblzap]]

I can see the effect (CSS being displayed only) using Firefox. IE shows an error
message:

--------------------------------------------------------------------------------
The XML page cannot be displayed 

Cannot view XML input using style sheet. Please correct the error and then click
the Refresh button, or try again later. 

Switch from current encoding to specified encoding not supported. Error
processing resource 'https://bugzilla.mozilla.org/a...

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
--------------------------------------------------------------------------------

Attachments are displayed as IFRAMEs, and the content that is sent to the
browser is announced with the MIME type of the attachment. The browser is then
responsible for displaying the attachment.

It seems what we're seeing is the way Firefox displays text/xml (the current
MIME type of the attachment in question) -- tags are omitted so that only the
CSS part is left over.

I think you might get better results if you specified text/plain as the MIME
type for these particular files.

Comment 2

[Heinz Kohl]

(In reply to comment #1)
--------------------------------------------------------------------------------
> 
> Attachments are displayed as IFRAMEs, and the content that is sent to the
> browser is announced with the MIME type of the attachment. The browser is then
> responsible for displaying the attachment.
> 
> It seems what we're seeing is the way Firefox displays text/xml (the current
> MIME type of the attachment in question) -- tags are omitted so that only the
> CSS part is left over.
> 
> I think you might get better results if you specified text/plain as the MIME
> type for these particular files.

Nice, and I think, correct -
the source sent may be very "correct"
but the view of the user (and/or the maintainer!!!) is through the spectacles of
 a browser - in our case mainly of mozilla type.

And what the maintainer is seeing, is indeed TOTALLY WRONG!!!

Look at the results - there is no work on the original error message I sent
since March!

It would even be AS STRANGE AS IMPOSSIBLE to feed the thousends and thousends
senders of error messages with the information:
"if the source is of some types, it isn't displayed by browsers in the expected
manner. There may be another way to send the data"

The cause of the unexpected behavior is of NO INTEREST AT ALL, it is the PLIGHT
OF THE PROGRAM, here Bugzilla, to send the data in manner which will lead to a
sufficient view for the maintainer, i.e. a correct output on the maintainers
screen, at least, to SEND INFORMATION, THAT HE's NOT GETTING A CORRECT VIEW; AND
WHAT HE HAS TO DO TO GET A CORRECT ONE.

Sorry, but a developer in commercial work seeing this in another way would be
without job instantly.
This is even true, when the error is only set up by a typical unsufficient user
program reaction.
It's an easy job for bugzilla, it has to work only on some actual browsers.
A son of mine had to take back 30000 correct CDs, tested on some dozen of
browsers and browser versions, W3C checked - they were crashing the system on
the ancient browser of the client.

Comment 3

[Marc Schumann [:Wurblzap]]

Simply put, it is impossible for Bugzilla to know how to preprocess a bunch of
bytes (that's what an attachment is; it can be anything at all) so that it's
displayed the way the submitter intended the bunch of bytes to be displayed.

Take HTML code for instance -- some (I'd say most) may want it to be displayed
in layouted view, others may want the code to display. Submitters may influence
the way Bugzilla asks the browser to display the bunch of bytes by specifying
the MIME type.

What we're seeing is correct -- the MIME type is text/xml, so the browser that's
being asked to display it that way tries its best to do it.

In your particular case, you want the code not to be interpreted, but to be
displayed as plain text -- ok, help Bugzilla to help the Browser, and set the
MIME type to text/plain.

Sorry; marking INVALID again.

Comment 4

[Heinz Kohl]

"What we're seeing is correct -- the MIME type is text/xml, so the browser
that's being asked to display it that way tries its best to do it."

I don't agree.

I'm seeing Bugzilla in a too thin way as dedicated to submit Mozilla errors; of
course, it has a wider application spectrum.
 
In this context I'm only a bug submitter, and I think, I've sent much more bugs
than most ordinary submitters.

Your interpretation has some hard consequences, which would be all but trivial
and not to be expected by a bug submitter.

1: I didn't expect, anybody is wanting to crash his browser or his system
because of viewing new error messages. Some of my error messages would just have
done that, when interpreted instantly.

2: Given the actual user information, the real purpose of MIME types isn't
visible for bug submitters.
Viewing the attachment, at this place it seems to be always shown as plain text.
I think, nearly no one is expecting to see it there in another mode, its a fact
(see original message!) that even mozilla developers don't 
(As a bug submitter I'd expected, that developers would have another interface
to the messages).

3: THERE SHOULD BE A THICK WARNING LIKE:
ATTACHMENTS INCLUDING MIME TYPES OTHER THAN TEXT ARE TO BE INTERPRETED BY ANY
BROWSER IN A VERY RESTRICTED ENVIRONMENT UNDER UNCERTAIN CONDITIONS AND SHOULD
EVEN THEN SHOW THE EXPECTED EFFECT AND MAKE NO TROUBLE, PLEASE USE TEXT/PLAIN IN
ALL CASES YOU'RE NOT PERFECTLY SURE. 
PLEASE USE TEXT/PLAIN, DON'T USE AUTOMATIC DETECTION, IT MAY HIDE STRUCTURE /
SEMANTICS OF YOUR ERROR MESSAGE.

TO VIEW FOR ATTACHMENTS TO FOREIGN ERROR MESSAGES MAY CORRUPT ZOUR SZSTEM!
EVEN WHEN SEEKING DUPLICATES, DON|T DOWNLOAD FILES!
*perhaps in looking for an attachment, I|ve changed unwillinglz the countrz
selection from german to US / don|t know, how to come back(

4: If the attachment is containing text, every developer would like to look at
the text before loading it.
After that, it would be an usual action to have e.g. a JavaScript function to
load this text depending to the MIME type, and the developer will see if that's
have sense at this moment.

5: for a visitor, it is very risky to look for attachments - they will be
interpreted!!

6: therefore it would be (and is in fact!) dangerous to look for parallel error
messages

At the moment, I think every submitter is thinking, to send an attachment using
the correct MIME type is for making it easier to check an error, not to make it
impossible.

Of course it would be possible to show an attachment in original form and
together with an interpretation of the MIME code.
As a submitter of browser bugs, it would be a very strange idea for me, a pure
view to my attachments could corrupt the browser of the maintainer or even kill
his system - some of my errors were indeed able to do that.

At a very least, there should be an information, that attachments with another
MIME type as text/plain will be interpreted and not showed up as text.

I thaught, the MIME type is to make it easier to see the semantics of the
message, and e.g. for sake of automatic preprocessing.

Sorry, as a consequence I'm seeing Bugzilla a bit as a problem then as a solution.

*No remark from mz side following(

Comment 5

[Marc Schumann [:Wurblzap]]

(In reply to comment #4)
> 2: Given the actual user information, the real purpose of MIME types isn't
> visible for bug submitters.
[...]
> 4: If the attachment is containing text, every developer would like to look
> at the text before loading it.

What comes to my mind for this is a checkbox on the attachment upload page along
the lines of "[ ] When displaying this attachment, display its source code".
With this checked, Bugzilla would send the attachment contents as text/plain
regardless of the real MIME type. The real MIME type would then be purely
informational, or maybe additionally useful for a "Display this attachment" link
on the page showing the source code.

Comment 6

[Heinz Kohl]

(In reply to comment #5)
> What comes to my mind for this is a checkbox on the attachment upload page along
> the lines of "[ ] When displaying this attachment, display its source code".
> With this checked, Bugzilla would send the attachment contents as text/plain
> regardless of the real MIME type. The real MIME type would then be purely
> informational, or maybe additionally useful for a "Display this attachment" link
> on the page showing the source code.
(.. just making an entry I promised not to do ..)

Good idea.  
With such a comment I hadn't had some days of work, and perhaps my original
error message from march would have been processed successfully a month ago.

It might be remarkable, that no one - not I, but also not the maintainer, was
thinking about using a browser with the capability for a look to the attachment
in an evaluated manner (Mozilla SVG instead of Firefox would have shown a fine
picture! Indeed - for pure browsing I'm always using a stable browser, not a
nightly build with even restricted error messaging, some of the mozilla
developers will do the same).

It isn't really a strange idea to use a stable browser without the newest and
therefore most critical features for a first look into the browser error
databank, and not just the error producing alfa test version.

Additionally I've the feeling, that the actual state is setting up a severe and
unnecessarily efficient distribution center for viruses/worms.
(Maybe I'll try to look for that in the later future)

Comment 7

[Heinz Kohl]

"Severity: trivial" - maybe, but for whom and for what sake?!

It was all but trivial for me to expect such a reaction, when I sent my first xml source as an error message appendix. 

This source was not seen by the maintainer - using a standard mozilla browser he was seeing no SVG/xml source at all, only its css part.

Therefore there was no error handling for some month.

This is indeed the worst case possible.

Some mozilla maintainers, e.g. the ones for bug #288165, seems to have another view to trivial situations as the maintainers for this bug 294634.

There is a trivial reaction by me - nearly no further unnecessary work to detect trivial bugs like mozilla bugs.

Sorry.

But you should think for a better training of maintainers and all bug message writers to avoid or to be able to cope with trivial, but irritating situations, when you're unable to make an user interface avoiding them.

Comment 8

[Marc Schumann [:Wurblzap]]

Don't let a single person's opinion disturb you. It seems like a whole bunch of INVALID bugs was marked "trivial" today for some reason.