Closed Bug 893776 Opened 11 years ago Closed 9 years ago

Placeholders instead of pictures shown in newsgroup posting bodies

Categories

(SeaMonkey :: MailNews: General, defect)

Product:
SeaMonkey
Component:
MailNews: General
Version:
SeaMonkey 2.19 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(seamonkey2.33 wontfix, seamonkey2.35 fixed, seamonkey2.36 fixed, seamonkey2.37 fixed, seamonkey2.38 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
seamonkey2.33 --- wontfix
seamonkey2.35 --- fixed
seamonkey2.36 --- fixed
seamonkey2.37 --- fixed
seamonkey2.38 --- fixed

People

(Reporter: kb8qeu, Assigned: h.figge)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: Workaround: See comment 28)

User Story

comm-central was merged to comm-aurora - no change needed here.
http://hg.mozilla.org/releases/comm-beta/rev/5dc7de6025fd    SeaMonkey 2.37
http://hg.mozilla.org/releases/comm-release/rev/fcd6e2b92e3d SeaMonkey 2.36
http://hg.mozilla.org/releases/comm-release/rev/2c5243aeba45 SeaMonkey 2.35 (SEAMONKEY_2_35_RELEASE_BRANCH)

Attachments

(1 file, 2 obsolete files)

try2 patch reformatted w/ checkin comment.
(deleted), text/plain
ewong
: review+
ewong
: feedback+
philip.chee
: approval-comm-aurora+
philip.chee
: approval-comm-beta+
philip.chee
: approval-comm-release+
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19 (Beta/Release) Build ID: 20130630011339 Steps to reproduce: Since I got the latest version, 2.19, my news groups stopped allowing images to come through. My version 1.1.16 still works. Version 2.17 worked fine. Contact me at kb8qeu@gmail.com or kb8qeu@suddenlink.net. The group I'm using is alt.binaries.pictures.scenic. Thanks in advance. Ed --- KB8QEU Actual results: My newsgroup won't load images anymore with the version 2.19 but does with version 1.1.16. As well as version 2.17. Expected results: Images to load automatically.
Summary: No images loading in newsgroups on version 2.19 but does with both version 1.16 and 2.17. ... Ed --- KB8QEU → No images loading in newsgroups on version 2.19 but does with both version 1.16 and 2.17
(Open) server to test with?
therube: Actually we can news://news.mozilla.org/mozilla.test.multimedia for this. This seems to be wfm on trunk, but I still have to try with SeaMonkey 2.19.
I'm still having the same problem with version 2.19!!! I want version 2.17 back! [ therube 2013-07-15 11:09:00 PDT (Open) server to test with?] The server I'm using is news.suddenlink.net. Does that help? I'm gettin frustrated with having to go to version 1.1.16 to get my news, or to use Fronte' Agent. Now what about the "Multiple part" images not loading as one image? I've yet to get any e-mails about these problems. Ed --- KB8QEU kb8qeu AT gmail DOT com
URL: alt.binaries.pictures.scenic
The test image that Frank posted is WFM in SeaMonkey 2.19. Ed, does that work for you? You can revert to 2.17 from here, ftp://ftp.mozilla.org/pub/seamonkey/releases/2.17.1 Do let us know if that is (again, still) working as expected where 2.19 remains broken? > No images loading in newsgroups What exactly do you mean by that? Is there broken link indicator or something like that? If you change the server from news.suddenlink.net to news.lga.highwinds-media.com does that make any difference? Is there a way to view the "source" in (Mozilla) News? Where would the actual "image" be stored? I see the .msf, & I can see Frank's message in there, but it would seem the actual image is automatically decoded & stored elsewhere? It being a "binary" newsgroup, is that different from Frank's "inline" image?
What I mean by "No images are loading from the news group" is that they use to automatically load for me to see. But now with 2.19, they don't! When I click on a post in, alt.binaries.pictures.scenic, with 2.19, it acts like it's doing something but nothing happens! No picture. With 1.1.16, it loads ok. This started when, SeaMonkey automatically updated to 2.19. I have not changed the server except to one in Washington DC which I use to get weather info. That is text only server. Where is news.lga.highwinds-media.com anyway? What is it's DNS? Suddenlink has all DNSs with the start address of 41, 42, and 44 blocked. Those are scammers in Nigeria and USSR. About multipart. Why does it work, putting the parts together to make a whole pic, with Fronte' Agent and never has with Netscape / SeaMonkey? Where was Frank's message again? I don't understand. Where is WFM? Ed --- KB8QEU
> Where is news.lga.highwinds-media.com West Virginia, supposedly. > putting the parts together to make a whole pic, with Forte Agent That is a different matter entirely, & seemingly likely never to be resolved. > Frank's message Set up a server: news.mozilla.org Then subscribe to: mozilla.test.multimedia In multimedia test, you should find the image he posted. (You & I can access news.mozilla.org, because it is open, where suddenlink requires a login.) > What is WFM? Works For Me. In other words, the image he posted loaded & displayed as expected. > You can revert to 2.17 from here... If you revert & it still does not work, then it could be a change on suddenlink's end, but then you do say 1.1.16 continues to work. (Surprising these days that an ISP even carries news groups.)
Sure version 1.1.16 still works! It is mostly better than 2,19. I use 1.1.16 to make my pages for myself, my Amateur Radio Club, and other clients. What should be changed on suddenlink's end? They will not change anything. I've delt withem a lot, mostly on anti-scam projects. "Set up a server: news.mozilla.org Then subscribe to: mozilla.test.multimedia" I will try to do that. Oh! BTW. I do have a BBS up since 1989. It's all text, no GUI needed. Ed --- KB8QEU
Still not displaying images in newsgroups using Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 Status bar indicates Loading Message... and never finishes. Images in posts from alt.binaries.pictures.scenic display using Thunderbird. From Thunderbird Message Source. Content-Type: image/jpeg; name="Ancient Civilizations P0307103.jpg" Content-Transfer-Encoding: base64 From SeaMonkey Message Source. Content-Type: image/jpeg; name="Miami & the Florida Keys P0321941.JPG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Miami & the Florida Keys P0321941.JPG" I have SeaMonkey and Thunderbird both configured to Display Attachments Inline.
Confirmed not working with SeaMonkey 2.30 (windows and linux) - works in Thunderbird. See: <https://groups.google.com/forum/#!topic/mozilla.support.seamonkey/mG1ChpBfajQ> for added info.
Confirm newsgroup graphics not displaying in Seamonkey 2.30, details as enumerated by WaltS48 and NoOp. Also, double-clicking on a filename (under "Attachments:" in upper right corner) displays text/alphanumeric, not graphics. Copying file to alternative location and opening with graphics program works as it should. This DID work correctly in SM 2.26.1, no known changes in configuration. All the above is the same with 2.30 running on another computer running XP SP3. My UA string: Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
@ Ed McKinney - re comments 11 & 12: This is not a "group", nor is it SeaMonkey support. Please refrain from commenting further in this bug report unless it is directly related to this bug.
Opening the same newsgroup in SM 2.19 & SM 2.30, 2.19, in most cases, either partially (IOW with the picture not displaying correctly but visible) or fully (correctly) decoded the images I looked at where SM 2.30 did not decode the images at all, showing a placeholder & "loading" on the statusbar. So while SeaMonkey 2.30 may not be decoding images, the issue with 2.30 looks to be different then whatever the issue was as originally described in this bug. Anyhow, only thing I see in Error Console is: > Error: TypeError: browsers[i] is undefined > Source File: chrome://navigator/content/tabbrowser.xml > Line: 331 Server: news2.neva.ru Group: alt.pictures.erotic, had a couple partially decoded images (SM 2.19) Group: alt.pictures.erotic.female, pictures fully, correctly decoded (SM 2.19)
Guess I should note that regardless of SeaMonkey version, the images as posted in the groups are fully correct. I can copy the page source (Ctrl+U), paste it into a file, dumy.txt, & manually decode that: > UUD.exe dumy.txt & that successfully outputs a correct beach-spy-eye_314.jpg. (That SeaMonkey seems to stink in decoding, in certain circumstances is a different issue again.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Easy test is to use the post in 'mozilla.test.multimedia - Subject: test: image attachment' and that way there is no need to subscribe to multiple newsgroups/servers.
The regression range for SM-Trunk Linux x86_64 follows. Does anyone see a suspicious checkin? Last good: 2014-06-04 20:34:00 PDT First bad: 2014-06-05 21:13:00 PDT
Hartmut: Do you have the hg/Mercurial revision ids handy for those two builds? That would be cool! See about:buildconfig for the mozilla-central revision ids. In the application.ini you can find the comm-central revision id, see the "SourceStamp=[...]" entry there.
I can do that. As a check i can provide also the content of the saved seamonkey-*.txt which used to contain this data. Until 2014-08-09 21:08:00 PDT. Now there is only an entry for c-c. For my current build about:buildconfig would not help to get the data for m-c. Last good: 2014-06-04 20:34:00 PDT Built from http://hg.mozilla.org/mozilla-central/rev/882826199076 SourceStamp=2608fae8b13b http://hg.mozilla.org/mozilla-central/rev/882826199076 http://hg.mozilla.org/comm-central//rev/2608fae8b13b First bad: 2014-06-05 21:13:00 PDT Built from http://hg.mozilla.org/mozilla-central/rev/4a552fb1ca38 SourceStamp=9477e9a40a03 http://hg.mozilla.org/mozilla-central/rev/4a552fb1ca38 http://hg.mozilla.org/comm-central//rev/9477e9a40a03
Just for once I have build a debug-build of SM-Trunk, tried to view an image in a NG and got an interesting message in the console. And in my run-log.txt. [15229] ###!!! ASSERTION: Parsing must result in an m_nntpServer: 'm_nntpServer', file /home/hafi/moz-work/src/mailnews/news/src/nsNNTPProtocol.cpp, line 1113 JavaScript error: chrome://navigator/content/tabbrowser.xml, line 331: TypeError: browsers[i] is undefined
TB was also affected by this bug for a short time. Trying c-c builds from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2014/06/ I discovered this range for Linux x86_64 using platform.ini: Last bad: BuildID=20140609030205 Milestone=32.0a1 SourceStamp=9305a8ec77fe First good: BuildID=20140610030209 Milestone=33.0a1 SourceStamp=9dc0ffca10f4
Any news, progress, resolution? I'm still facing this frustrating bug (recent versions of Seamonkey; v2.32.1, Windows): nntp inline attached images won't show (status bar displaying "Loading image", and mouse cursor stuck "in progress".
(In reply to laimis from comment #23) > images won't show (status bar displaying "Loading image", and mouse cursor Loading *Message*
Since 2.26.1, all versions will not show images in newsgroups.All I see are place holders with a "broken" image icon. Not being a coder, I have no idea where to look.
Providing the regression range for SM and the fixing range for TB should be more effective than voting. ;)
Images are shown when the message has been downloaded beforehand. As workaround: 1. Subscribe to the newsgroup 2. Go to Menu - File - Offline - Download/Sync Now... 3. Check Newsgroup messages 4. Click Select and choose the relevant newsgroup 5. Click OK The download may last some minutes.
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: Workaround: Download Message beforehand, see comment 20 → Workaround: See comment 28
Still REPRODUCIBLE with EN-US Seamonkey 2.33 Build 20150308222025 (Default Theme) on German WIN7 64bit: 1. If news.mozilla.org not subscribed already: in Mail Client: 'Menu 'Edit ► Mail and Newsgroups account settings ► [Add Account] ► Account Name := "news.mozilla.org" ► Add Name, Email Address, ... ► [ok] » Account will be added 2. 'Click Account ► Manage Nesgroup Subscriptions ► Show items that contain := "mozilla.test.multimedia"' » one hit will be shown 3. 'click hit ► [Subscribe] ► [ok] » subscribed group will be added, after 'Bet Msgs' list of postings will be shown 4. If necessary: 'Menu View ► Messages body as ► Original HTML 5. Date 2015-03-12 Shows a posting NTMM, "once upon a time" Expected: Picture with chimney on sheet of music background shown Actual: Only 1 placeholder a) Works fine with thunderbird 31.5.0 b) I compared message source text from SeaMonkey and Thunderbird, source is 100% identical from SeaMonkey and Thunderbird. c) So reporter's assumption "pictures not loaded" seems to be wrong, pictures are loaded, but not shown. d) Opening posting in stand alone window (doubleclick on posting) does not heal the problem e) for me Workaround in comment 28 does not work, may be I misunderstand something? f) Workaround tested successfully: 1. rightclick mozilla.test.multimedia 2. Tab: Synchronization ► Check "Select this NG for offline use" ► [ok] » Download will start, afterwards pictures will be shown g) unfortunately I do not have skills to find regression range for SM and the fixing range for TB
URL: alt.binaries.pictures.scenic → news://news.mozilla.org/mozilla.test....
status-seamonkey2.33: --- → affected
Keywords: regression
Summary: No images loading in newsgroups on version 2.19 but does with both version 1.16 and 2.17 → Placeholders instead of pictures shown in newsgroup posting bodies
(In reply to :Hb from comment #28) > Images are shown when the message has been downloaded beforehand. > > As workaround: > 1. Subscribe to the newsgroup > 2. Go to Menu - File - Offline - Download/Sync Now... > 3. Check Newsgroup messages > 4. Click Select and choose the relevant newsgroup > 5. Click OK > > The download may last some minutes. Finer grain workaround: select message(s), right click, "Get Selected Messages" and SM will show images (when messages are reloaded/reselected).
(In reply to laimis from comment #30) > (In reply to :Hb from comment #28) > > Images are shown when the message has been downloaded beforehand. > > > > As workaround: > > 1. Subscribe to the newsgroup [snip] > > Finer grain workaround: select message(s), right click, "Get Selected > Messages" and SM will show images (when messages are reloaded/reselected). Please read the bug report comments... the "workaround" was already mentioned by Craig in comment #10: "Copying file to alternative location and opening with graphics program works as it should."
(In reply to Rainer Bielefeld from comment #29) > Still REPRODUCIBLE with EN-US Seamonkey 2.33 Build 20150308222025 (Default > Theme) on German WIN7 64bit: Also 2.33 linux: User agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33 Build identifier: 20150308222602 and User agent: Mozilla/5.0 (X11; Linux i686; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33 Build identifier: 20150308222504
(In reply to NoOp from comment #31) > (In reply to laimis from comment #30) > > (In reply to :Hb from comment #28) > > > Images are shown when the message has been downloaded beforehand. > > > > > > As workaround: > > > 1. Subscribe to the newsgroup > [snip] > > > > > Finer grain workaround: select message(s), right click, "Get Selected > > Messages" and SM will show images (when messages are reloaded/reselected). > > Please read the bug report comments... the "workaround" was already > mentioned by Craig in comment #10: > > "Copying file to alternative location and opening with graphics program > works as it should." Please read what others write and mean. It's not the same as saving the attached file and opening it. It's not the same as copying message to alternate location. It's not the same as making all newsgroup offline. It's another and distinct workaround: select particular message(s) with attached images, right click, "Get Selected Messages" and images of the selected message(s) will be shown.
(In reply to laimis from comment #33) > (In reply to NoOp from comment #31) > > (In reply to laimis from comment #30) > > > (In reply to :Hb from comment #28) > > > > Images are shown when the message has been downloaded beforehand. > > > > > > > > As workaround: > > > > 1. Subscribe to the newsgroup > > [snip] > > > > > > > > Finer grain workaround: select message(s), right click, "Get Selected > > > Messages" and SM will show images (when messages are reloaded/reselected). > > > > Please read the bug report comments... the "workaround" was already > > mentioned by Craig in comment #10: > > > > "Copying file to alternative location and opening with graphics program > > works as it should." > > Please read what others write and mean. It's not the same as saving the > attached file and opening it. > It's not the same as copying message to alternate location. It's not the > same as making all newsgroup offline. It's another and distinct workaround: > select particular message(s) with attached images, right click, "Get > Selected Messages" and images of the selected message(s) will be shown. Mea Culpa... your workaround does indeed work for me w/2.33. Thanks.
I spoke too soon. Does not work for this png message in news.mozilla.test.multimedia: ('View|All Body Parts' enabled & selected) news://news.mozilla.org:119/mailman.9400.1422369710.26608.test-multimedia@lists.mozilla.org Subject: Re: test From: boxcars@gmx.net --MP_/dfS0O+V49lJvqRwhKY=eFCk Content-Type: image/x-apple-ios-png Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=mullen-post-screenshot.png Works for these jpg's: news://news.mozilla.org:119/mailman.411.1425421655.4168.test-multimedia@lists.mozilla.org image attachment --------------020101070905080505080708 Content-Type: image/jpeg; name="Untitled.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Untitled.jpg" news://news.mozilla.org:119/mailman.411.1425421655.4168.test-multimedia@lists.mozilla.org --------------030700050704080603000706 Content-Type: image/jpeg; name="bjjidhjj.jpg" Content-Transfer-Encoding: base64 Content-ID: <part1.07030707.02070008@edmullen.net> Content-Disposition: inline; filename="bjjidhjj.jpg"
> Content-Type: image/x-apple-ios-png This doesn't look to be standard MIME type. And AFAIK SM won't show that attached image even if it were normal mail message.
(In reply to laimis from comment #36) > This doesn't look to be standard MIME type. In case it can help, I've attached the same PNG to a new message, this time with the standard PNG MIME type. news://news.mozilla.org:119/mailman.2023.1429727761.29280.test-multimedia@lists.mozilla.org
(In reply to »Q« from comment #37) > (In reply to laimis from comment #36) > > > This doesn't look to be standard MIME type. > > In case it can help, I've attached the same PNG to a new message, this time > with the standard PNG MIME type. > > news://news.mozilla.org:119/mailman.2023.1429727761.29280.test- > multimedia@lists.mozilla.org Now it's even worse: non standard image pretends to be standard MIME image/type. It's not related to this particular bug and SM; apple screwed up (well, modified) png and now someone is trying to load it as a regular/standard png. Try opening it in your favourite picture viewer (which most likely also doesn't support apple's png, although specialized and more graphics capable than SM). No luck? :-)
(In reply to laimis from comment #38) AFAIK, it is a standard PNG. It opens fine in all my image viewers, including Firefox. All of my viewers are depending on libpng-1.6.16. It was created with kscreenshot, also depending on that version of libpng. `file` only depends on the headers of the PNG, but FWIW, here's the output: $ file mullen-post-screenshot.png mullen-post-screenshot.png: PNG image data, 843 x 250, 8-bit/color RGB, non-interlaced
(In reply to »Q« from comment #39) > (In reply to laimis from comment #38) > > AFAIK, it is a standard PNG. It opens fine in all my image viewers, > including Firefox. All of my viewers are depending on libpng-1.6.16. It > was created with kscreenshot, also depending on that version of libpng. > `file` only depends on the headers of the PNG, but FWIW, here's the output: > > $ file mullen-post-screenshot.png > mullen-post-screenshot.png: PNG image data, 843 x 250, 8-bit/color RGB, > non-interlaced Well, i'm taking my words back. Image attached by NoOP didn't look to be standard png, and then you, so i thought... Things are different then, but no much. Still it's not related to this particular bug: it's a multipart/mixed bug or even malformed (non RFC standard) headers. There are some reports on this issue; one of them: https://bugzilla.mozilla.org/show_bug.cgi?id=61815
And surprisingly (!) that attached image shows (SM 2.33.1, Windows), so it's not a problem (at least for me and others using that SM version). Still it won't show automatically; one need to use workaround.
(In reply to comment #41) It's not surprising. comment #40 is incorrect. The headers are fine and multipart/mixed isn't involved at all. If the example post helps people work on the bug, great, but it's generating too much bugnoise.
Bisecting the range in Comment 19 results in The first bad revision is: changeset: 186855:d405928cb934 user: Honza Bambas <honzab.moz@firemni.cz> date: Thu Jun 05 18:27:38 2014 +0200 summary: Bug 999577 - disable addon access to cache v1 IDLs, r=michal+jduell Verified by backout. The problem is gone then. In current SM-Trunk backout is no longer possible.
How did TB fix the issue? Bisecting the range in Comment 22 results in The first good revision is: changeset: 16316:f54c834090c2 user: Honza Bambas <honzab.moz@firemni.cz> date: Sat Jun 07 05:34:00 2014 -0400 summary: Bug 1022133 - Disable HTTP cache v2 for Thunderbird. r=jcranmer, a=me Is there now enough information for someone familiar with the cache? If such a someone exists and cares enough about fixing the issue for SM. :-)
Attached patch try1 (obsolete) (deleted) — — Splinter Review
Looking closer at Comment 44 inspired the fix try1. Works for my SM-Trunk Linux x86_64.
Attachment #8607263 - Flags: review?(neil)
Comment on attachment 8607263 [details] [diff] [review] try1 Works for me on a Win8.1 system. Setting up review to neil.
Attachment #8607263 - Flags: review?(neil)
Attachment #8607263 - Flags: review?(iann_bugzilla)
Attachment #8607263 - Flags: feedback+
Assignee: nobody → h.figge
Comment on attachment 8607263 [details] [diff] [review] try1 This doesn't break the cache preference pane does it?
(In reply to neil@parkwaycc.co.uk from comment #47) > Comment on attachment 8607263 [details] [diff] [review] > try1 > > This doesn't break the cache preference pane does it? It is the same fix TB used. I haven't seen side effects. So far. :) To be really sure someone with knowledge should investigate.
Status: NEW → ASSIGNED
Comment on attachment 8607263 [details] [diff] [review] try1 I would prefer these are added at the end of the file rather than at the beginning. r=me with that addressed.
Attachment #8607263 - Flags: review?(iann_bugzilla) → review+
Attached patch try2 (obsolete) (deleted) — — Splinter Review
Moved the changes to the end of the file. The comment should be kept, IMHO. For a checkin try2 must be converted to a proper hg-patch. Anyone? :)
Attachment #8607263 - Attachment is obsolete: true
Attachment #8614397 - Attachment is obsolete: true
Attachment #8614427 - Flags: review+
Attachment #8614427 - Flags: feedback+
Comment on attachment 8614427 [details] try2 patch reformatted w/ checkin comment. [Approval Request Comment] Regression caused by (bug #): User impact if declined: images not shown in newsgroup posts Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String changes made by this patch: None
Attachment #8614427 - Flags: approval-comm-release?
Attachment #8614427 - Flags: approval-comm-beta?
Attachment #8614427 - Flags: approval-comm-aurora?
Comment on attachment 8614427 [details] try2 patch reformatted w/ checkin comment. a=me for all branches plus CLOSED TREE
Attachment #8614427 - Flags: approval-comm-release?
Attachment #8614427 - Flags: approval-comm-release+
Attachment #8614427 - Flags: approval-comm-beta?
Attachment #8614427 - Flags: approval-comm-beta+
Attachment #8614427 - Flags: approval-comm-aurora?
Attachment #8614427 - Flags: approval-comm-aurora+
Blocks: SM2.35-Uplift
comm-central was merged to comm-aurora - no change needed here. http://hg.mozilla.org/releases/comm-beta/rev/5dc7de6025fd SeaMonkey 2.37 http://hg.mozilla.org/releases/comm-release/rev/fcd6e2b92e3d SeaMonkey 2.36 http://hg.mozilla.org/releases/comm-release/rev/2c5243aeba45 SeaMonkey 2.35 (SEAMONKEY_2_35_RELEASE_BRANCH)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-seamonkey2.33: affected → wontfix
status-seamonkey2.35: affected → fixed
status-seamonkey2.36: affected → fixed
status-seamonkey2.37: affected → fixed
Resolution: --- → FIXED
Blocks: 1066998
User Story: (updated)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: