Closed Bug 252782 Opened 20 years ago Closed 14 years ago

inline attachments when they are images

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

enhancement

Tracking

()

VERIFIED DUPLICATE of bug 1472522

People

(Reporter: jpyeron, Assigned: guy.pyrzak)

References

Details

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: 

when the attachment is an image, then inline it.

Reproducible: Always
Steps to Reproduce:
Attached patch quote urls for attachment images (obsolete) — Splinter Review
read bug 222861
You probably want to only do this when the user really wants it.

*** This bug has been marked as a duplicate of 222861 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Depends on: 222861
Resolution: DUPLICATE → ---
Attached patch bugzilla-252782-v1.00.diff (obsolete) — Splinter Review
regex replacement,

maybe we should use the figure syntax suggested in bug 222861
Attachment #154120 - Attachment is obsolete: true
Possibly...  I think you especially want to 
a) preserve the option of clicking on the link/image to go to the
edit-attachment page.
b) only inline non-obsolete images visible to the user.
c) possibly, give the viewer some control over this (see bug 262592)
this does only inline non-obsolete images. 
hmmm, in regards to the cookie and template idea, it would require more work 
than a user pref mod. But I like it, just not now.

investigating the 'edit click' issue.
uses figure notation now
GetAttachmentLink will take an option to "inline"
edit click fixed
Attachment #160843 - Attachment is obsolete: true
Having graphics inline means that everyone who views the bug has to download it,
whether they are interested in it or not. It means it's possible for some idiot
on DSL to attach a 2MB graphic to a bug and make in unusable for people on modems.

Why is it so much more trouble to click once to see a graphic?

Gerv
It is a necessary feature for several sites.  Naturally, it needs to be
controlled by a site-wide switch and enabled/disabled by some reasonable method
(like a cookie).
Maybe provide a scaled-down version of the image with a reduced width and height?
Assignee: myk → jpyeron
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 160849 [details] [diff] [review]
bugzilla-252782-v1.02.diff

I've heard libMagick or ImageMagick or something like that can be used to
create those thumbnails.

So practically we need a parameter, probably boolean, to control whether
thumbnails should be displayed inline or not. An external library will be used
for those, and the additional dependency should be marked in checksetup.pl as
optional.
Attachment #160849 - Flags: review-
(In reply to comment #9)
> Having graphics inline means that everyone who views the bug has to download it,
> whether they are interested in it or not. It means it's possible for some idiot
> on DSL to attach a 2MB graphic to a bug and make in unusable for people on modems.
> 
> Why is it so much more trouble to click once to see a graphic?
> 
> Gerv

If you have a slow connection then you should turn off image downloads in your
browser. Making the option site wide will punish people on running bugzilla over
fast connections. This is already a solved problem in the browsers.

As for the second point, making the computer work harder to save a click makes
sense because peoples needs should always come before the needs of the computer.
A comment about the thumbnail images.

My guess is that this is going to be used to store screen shots of broken
software 99% of the time. If you do an alt-print screen in windows, and paste it
into ms-paint you will get a huge 8 meg BMP file. However, if you encode the
image into a jpg or png, it will compress way, way down (say 8mg -> 100k)
because of the limited number of colors found in normal screen shots. 

So, another way at this, is to attempt to translate the posted images into png
or jpeg before storing. This will keep the size of the attachment table down and
allows you to send out the image as is at runtime lowering the load on the
server when displaying bugs. If the images are small because of the good
compression, then it lowers the need to have this as a site option.
I just noticed bug 302083. This patch will convert BMP to PNG. The thumbnail
part of this bug I think it redundent if 302083 is accepted.
QA Contact: mattyt-bugzilla → default-qa
(In reply to comment #9)
> Having graphics inline means that everyone who views the bug has to download
> it,
> whether they are interested in it or not.

You can use JavaScript. Images are not displayed by default. When you click a 'attachment xxxxxx' link in a comment, the attachment would be displayed inline if it's an image. This way, you don't need to attachment.cgi, then go back to show_bug.cgi again. You would see both comments and images in the same screen. If you don't want to view an image, don't click on its link.
*** Bug 362337 has been marked as a duplicate of this bug. ***
So if we provide:


System & User option to "inline" image links
System & User option to scale/limit inlined image links (req depend on some lib)


we are good to go?
what protects the system from a hacker deciding to root bugzilla installs when there's a known exploit in libimgmagic? :)

this increases the attack surface for bugzilla tremendously, there are lots of public bugzillas around.

i think we should consider css that can inline images on :hover where the text clearly indicates that this will happen. with a css/user pref to not support this feature.

as a bonus i can use user agent css to disable this feature per browser.... although that probably also argues for a way to have the hovers default to off for a user but be something that user css can enable.
Dear All,

I hope I can provide some feedback as a user. 
It is also related to https://bugzilla.mozilla.org/show_bug.cgi?id=362337.

Can you feel what's the status on this. Is it coming or not ?

For bug reporters this is a serious speed up, since very often the screenshot of the program having the bug shows 10 ten more then putting it in words. However if one has to put it first in a separate file (which as mentioned above, not always provide the nicest encoding (eg bmp)) and only then attach it, is a very slow process, where the paste of the screen capture is very intuitive and a good speed-up.

I also agree on the fact that maybe it should be an option, so it can be switched off for 'slow users', but as said, the browser can prevent loading the images -> issue solved. But when one has a fast connection to the internet or one is on a private network, all these things become hardly an issue.

Please please provide this functionality ((jira also provides this, and there it looked a very useful feature).

kind regards
Lieven

PS : a little bit related : it would be very nice when one creates a bug, that at that time whatever attachment could already be added. The only way I see now is first create a bug, and then afterwards one can add attachments [attachments generally speaking so not images : log files, configuration files, ...]

bugzilla already lets you add attachments when you file bugs.

note that we're now seeing spammers post attachments to bugzilla w/ various obscene content. the feature proposed here means a risk of NSFW spam appearing when you load bugs you need to read from work.

Oddly enough, it's considerably easier to do a free text search of bugs for words than it is for pictures "showing" problems. the arguments in favor of this feature are poor.
The last comment is dated 2007-08-05.  Has there been any progress on this since then? I'm very interested as I'm looking for an easy way of attaching images/screenshots to text fields in Testopia.  Currently, the only option is to add an attachment first, and then reference to that attachment in the text field by modifying the HTML source code.  I'm hoping for an easier solution. Thanks...
I was planning on working on this in the future, but there is a long list of things on my plate, so sorry about that.
Assignee: jpyeron → create-and-change
Attached patch Patch v1Splinter Review
Attachment #429578 - Flags: review?(mkanat)
Attachment #429578 - Flags: review?(LpSolit)
Assignee: create-and-change → guy.pyrzak
Status: NEW → ASSIGNED
Target Milestone: --- → Bugzilla 3.8
  I think that this is a feature that would be more appropriate in an extension. The arguments against the feature on the bug are strong, and there doesn't seem to be broad user data encouraging the implementation, though there does seem to be a definite set of users that would be benefited. Implementing it as an extension would also allow more features to be added to it, such as displaying small thumbnails of the image, adding a preference to display them or not, etc.
Priority: -- → P4
If we do all the complicated thumbnail stuff yes, but this version give a LOT of functionality without having a negative effect on loading the page and doesn't require any fancy thumbnail stuff.

Also how do we mark a bug as "should be an extension"?
Status: ASSIGNED → RESOLVED
Closed: 20 years ago14 years ago
Resolution: --- → DUPLICATE
Target Milestone: Bugzilla 3.8 → ---
Comment on attachment 429578 [details] [diff] [review]
Patch v1

  This is r- in favor of having this as an extension, which pyrzak has, I believe, already written. :-)
Attachment #429578 - Flags: review?(mkanat)
Attachment #429578 - Flags: review?(LpSolit)
Attachment #429578 - Flags: review-
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.