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:
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 ***
Created attachment 160843 [details] [diff] [review] bugzilla-252782-v1.00.diff regex replacement, maybe we should use the figure syntax suggested in bug 222861
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.
Created attachment 160849 [details] [diff] [review] bugzilla-252782-v1.02.diff uses figure notation now GetAttachmentLink will take an option to "inline" edit click fixed
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?
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.
(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.
*** 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.
Created attachment 429578 [details] [diff] [review] Patch v1
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.
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"?
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. :-)