Closed Bug 180073 Opened 22 years ago Closed 22 years ago

Bugzilla rejected a screenshot uploaded as a bug attachment because the attachment engine behind Bugzilla isn't Jpeg2000 compliant?

Categories

(Core :: Graphics: ImageLib, enhancement)

PowerPC
macOS
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 36351

People

(Reporter: Xapplimatic, Assigned: mjudge)

Details

(Keywords: meta, qawanted)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

Tried to upload a .jp2 screenshow of a rendering layout issue in Mozilla, but
Bugzilla attached a comment saying that the file contained errors and wouldn't
allow direct viewing to a browser.  Furthermore, downloading the link back to my
computer and viewing it in a picture viewer instead of Mozilla proves that the
file was in tact.  Best guess is the file attachment scanning prowess of
Bugzilla is not complaint with JPEG 2000 standards.  JPEG2000 support is native
in Mac OS X as of Jaguar release as part of the Quicktime media layer.  Other
platforms should be supporting it by now as well.. 

Reproducible: Always

Steps to Reproduce:
See bug #180067 in which this problem became an issue to documenting a bug.

Actual Results:  
Bugzilla rejected the file attachment and refused to send it to the browser for
viewing.

Expected Results:  
Bugzilla should accept file attachments with the .jp2 extension as valid jpeg
image formats and should be able to parse them under published standards to
check for file integrity.  In the very least if the engine can't verify jpeg
2000 picturs at this point, it should allow files by that extension to pass as
valid for the meantime so this more efficient format can be used in bugzilla
file attachments.

Looks like this has already been discussed as a standards compliance issue for
Mozilla.. let's hurry this up people, two years have passed! See bug #36351.
This is a bug in Mozilla, not Bugzilla.

Try viewing said attachment in some other browser, and you'll see.

I'm almost positive this is a dupe, too.
Assignee: myk → mjudge
Component: Attachments & Requests → Image Conversion Library
Keywords: qawanted
Product: Bugzilla → Browser
QA Contact: matty → tpreston
Whiteboard: dupeme
Version: unspecified → other
Just FYI, Bugzilla doesn't care WHAT you upload as an attachment, it will save
it, and will spit it back to your browser the same way it received it.  In this
case, your browser is choosing not to display the image, and is displaying that
message instead.

*** This bug has been marked as a duplicate of 36351 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
OK, I see what you were saying now.  The bugzilla versus mozilla confusion was
caused by the way the edit attachment page is laid out after uploading the image
files combined with the way in which Mozilla handled the error.  When I clicked
edit, next to the file name, I found the text error message (which I now know is
from Mozilla) in the same font set inside an outlined box next to the file name
as if it is a comment attached to the file...  That, and the clickable button
below the box reads "Edit attachment as Comment" as if that box is a comment to
be edited.. 

I can see how confusion can be created in a situation like this being there is
no real indication from Mozilla (or Chimera) by font size/type/color
differentiation to flag that text as an error in Mozilla and not from the server
in response to an upload, nor is there an icon attached to the text that flags
it as an error by Mozilla, etc.. Nothing to communicate that the text error
message was generated live by the browser and not the site as a response to the
upload.  i.e. The normal cue from a browser to a user is to display a
broken-image icon of some kind when an error like this is encountered as a place
holder instead of a text error (or the text message is very short in nature like
"cannot diplay image" in a very condensed font accompanying a broken-image icon.  

Perhaps Mozilla needs to make more clear where it can't load an image for one
reason or another by putting a token broken-image icon in lieu of them as a
placeholder to make it more obvious as it is handled in other popular browsers.
Keywords: meta
The Image Conversion Library component is going away.
Component: Image Conversion Library → ImageLib
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.