While working on a .docx or .xlsx file, pictures are replaced with "read error" message when opening file. Steps to reproduce are given here: https://bugs.freedesktop.org/show_bug.cgi?id=33393#c56: 1- started docx document in Office 2010 on Windows 7, added text, a few pictures, and table of contents. 2- opened docx in LO 3.5.4 on Mac Lion. Made various edits and added about 13 jpeg photos using Insert > Picture > From File in various places in the document. I did crop one of the images in LO and edited a few with "Edit with External Tool" (Mac Preview rotation) and all seemed okay from those. 3- re-Saved the file as docx and dropboxed it 4- re-opened the docx file at work today and got the following results. Probably all recent comments on this bug https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/157249 are also about the same bug.
[Quotation from https://bugs.freedesktop.org/show_bug.cgi?id=33393#c56 continued: Results after step 4:] * MS Office 2010 will not open it now and says it has an error. * Libreoffice 3.5.4 on Windows 7 will open it, but there are read-error notices where the pictures should be. * I also notice that the file is 4MB, which would be small considering that many pictures. They would have been a few MB each. * Also, the few images that were added originally in step 1 are still present and okay. All other images are missing with read-error. ---- @okko7: Thank you very much for moving the discussion to a new bug report! I will see if I can reproduce (and therefore confirm) this new report ... (Changed 'Component' to 'LibreOffice', because not only Writer is affected, but also Calc, and maybe Impress).
Another symptom of the horrific design behind image management.
Created attachment 64351 [details] Sample .docx file with missing images, created with LibO 3.5.5.3 REPRODUCIBLE with LibreOffice 3.5.5.3 (Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21), German langpack installed, on MacOS X 10.6.8 (Intel). To test, I used the steps given by Geoff King in https://bugs.freedesktop.org/show_bug.cgi?id=33393#c58: > 1-opened LO and made sure autosave was on, and it is by default > 2-changed autosave to 1 minutes (as noted in other comments) although it > doesn't work at other intervals either. I figured it would be more likely to > have problems if it autosaved more often > 3-started new file and saved as docx > 4-Added some text and formatting and a few images here and there, while > waiting a few minutes between. Also clicked the save button once or twice > to save the file between waits and adding images. > 5-After about 10 minutes and minimal additions, I saved the file, close it, > and closed LO. > 6-Re-opened the file in LO and the first image I added was read-error. The > other images were present, but some in slightly wrong places. My results are even worse: I added 2 PNG images and one JPEG image to the page, and all three are lost: I only see grey rectangles with the broken image symbol and the red notice "Read-Error". The images also lost the wrap settings I added to them -- both the direction of wrap-around (Before or After or Parallel ...) and the distance for text from the image margins are missing, all reset to default values. Only the position and size of all three images seems to be correct.
Updated Status and Summary
Also REPRODUCIBLE with LibreOffice 3.6.0.1 (Build ID: 73f9fb6), German langpack installed, again on MacOS X 10.6.8 (Intel). Creating and editing an .docx file following the steps cited in comment #3 gives me exactly the same results as said in comment #3. However, at least for now I can't reproduce the bug with Impress, so AFAIK Writer (.docx) and Calc (.xlsc) files are affected. (But maybe someone else can manage to reproduce this with Impress, to, so keep on testing ;-)
I seem to have a similar problem on Ubuntu 12.10 with LO 3.6.2.2 : Since I started exchanging .odt documents between my system and a Windows system with Microsoft Office, using tracked changes and comments. Every so often my images disappear with the message "Read-Error" and the broken image icon.
Version 3.6.0.2 (Build ID: 360m1(Build:102)) on Mint Linux Maya, same problem. BIG problem!
FYI using Version 3.6.0.2 (Build ID: 360m1(Build:102)) on Mint Linux, problem remains.
*** Bug 61674 has been marked as a duplicate of this bug. ***
Issue is still present with Version 4.0.0.3. > *** Bug 61674 has been marked as a duplicate of this bug. ***
*** Bug 58895 has been marked as a duplicate of this bug. ***
It looks like the problem is not specifically related to autosaving, but to saving in odt in general, since a similar problem was reported in Bug 63058 and Bug 62808. The problem can be reproduced by: 1. open and odt file with images 2. change it 3. save it (as odt) 4. save as docx 5. close the document 6. open the docx version: images are missing If step 3 is omitted, the docx file is OK. So I suggest that Bug 63058 and Bug 62808 be marked as duplicates of this one. Milos
*** Bug 62808 has been marked as a duplicate of this bug. ***
This issue has been there through all of the V4 versions up to 4.0.2. I can observe this bug every day : I receive docx files from colleagues which contain inserted images. I open them using LibreOffice and save them again as docx, usually using a different name, open them again : images have disappeared, either giving a read error or just an empty box ( I have observed both problems within the same file). When I open the resulting docx file with a zip programm and have a look in the mdeia folder I can see actually many imageXX.png or .emf files that either only contain a white rectangle or are corrupted. I have done this very fast after opening, I would guess before autosave has saved, the problem does not occur, so I actually also believe that this has something to do with the autosaving. This is a very annoying bug as everytime I return a document to a colleague all of the images are lost. I hope that this will be resolved rapidly. Cheers Oliver
Still present in version 4.0.3, 'losing' images in docx and xlsx files severely reduces interoperability LibreOffice - MS Office.
*** Bug 63059 has been marked as a duplicate of this bug. ***
I notice the same and a DOCX file. If I save and keep it as ODT, no problem. I've not NEEDed to use DOCX. If ODT is not an option for you, I suggest that you use DOC as a temporary workaround. If you notice that graphics saved in DOCX with earlier versions of LO, please mark this as a REGRESSION in Whiteboard. Something odd in this reporting: I see version indicated as "3.5.3 release", but detailed reports shows "3.5.4" to be the earliest version the bug is observed. Please confirm if this is a mistake. Perhaps it was mistakenly indicated by someone reporting the bug for 3.5.5.3. As I've learn, the version indicated should be the first version the bug is noticed. In any case, please correct it to avoid confusions.
Out of interest, please could someone else test using v4.1.0.1? Previously I had been able to reproduce this issue with a docx file easily, but after trying today I was unable to reproduce the problem and am keen to find out if this was a fluke or not. Tested on Win8 64bit.
Thanks a lot for looking into this matter, Rob. I hope this time, the bug will get tackled sooner. Unlike my original report (bug 58895), which went unnoticed for over 4 months and in the meanwhile the file from the download link had been automatically removed. ^^ (30 days no download) I reuploaded the unchanged files to http://ul.to/er0yvxmb The bug with the read error DOES exist in the official Pre-Release Version: ---- Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 OS: Windows 7, 64bit (but with the x86 executables, as the only ones available) Language: German for both ---- The saved and broken png-Image (rename *.docx to *.zip and open \word\media\) consists as before only of the first 8 bytes, a part of the png header, instead of the 8034 bytes of the original png. I padded the original png with zeros at the end to about 16KiB (i.e. all the same logical files and sizes, but physical filesize is bigger.) and when the changed document - removed/added a space somewhere - is saved, the picture gets saved without the zeros at the end, i.e. the filesize is read/computed from the png header before saving. ( http://ul.to/5kv96od7 ) Therefore, it's not the physical file that is kept! Tracking the pn RAM andng contents/datastructure i debugging the program step by step should reveal, why only the first 8 bytes are saved. My guess for the bug: Overwriting or not setting the stored file length or using/setting/computing the wrong value. (including the one that is calculated from the png-header informations) I don't have enough time in the next weeks/months to setup the LibreOffice development tools and look into the source code, but if you can provide me a download link to the next binaries (english only would be OK), I can test it again on my PC for sure.
>Tracking the pn RAM andng contents/datastructure i debugging the program step by >step should reveal, why only the first 8 bytes are saved. Sry for the misplacement, it should read as follows: --- Tracking the png contents/datastructure in RAM and debugging the program step by step should reveal, why only the first 8 bytes are saved. ---
I'll try to help but am not a coder on the project, apologies if I gave that impression. The debugging method suggested is probably beyond me right now (in skill and available time). Looking at the example files you've provided though, it certainly does look as though the PNG file only consists of the PNG signature as described here: http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.2 (confirmed by loading the file in a hex editor and it matches perfectly).
Have confirmed this does still occur in 4.1.0.1 under both of the methods described above. To re-iterate... METHOD 1: Ensure Save AutoRecovery information is on, and set to save every 1 minute to make testing easier. Open an ODT document with an image, save as DOCX format. Add a space to the document text. Wait until the automatic recovery save is performed. Save the DOCX file. Once re-opened the images will be missing. METHOD 2: Open an ODT document with an image, save as DOCX format. Export a PDF document, either using the button in the toolbar or the File > Export as PDF menu option. Add a space to the document text. Save the DOCX file. Once re-opened the images will be missing. This behaviour occurs when when Save AutoRecovery information is switched off. It should be noted I did not get consistent results with how many images were not displayed. In one of my first tests, all images were removed. In subsequent tests, just the image on the first page was removed.
After reading comment 21, that no file specific content is saved and the 8 bytes are exactly the png file signature, I tried something else. Instead of a png file in the MS docx file I used a JPEG file (saved as such inside the docx * ) and got interesting results: When a read error occurs, the JPEG file is now an empty 8 bytes PNG file! The file name stays the same and only the file extension is changed to png. This means in my case, the PDF export most probably replaces a pointer/reference or the file content and overwrites it with an empty png datastructure. Files of the experiments can be found at http://ul.to/cmxo0uat . I see two (relatively) simple solutions to this problem: - Find the address of the JPEG datastructure in RAM and track it and all its references/pointers/members/fields. One of these gets changed when it shouldn't and you have the culprit codeline. - (As workaround) Make a deep copy of the complete, currently displayed document and use this for auto-save and pdf export. The PDF in my experiments was exported correctly. Please inform some other developers, who could work on this issue as it is really annoying having to keep a manual backup of all files, when working together with someone who uses MS Office with docx as standard file format and the Office Version might not be able to open odt files. * rename *.docx to *.zip and go to /word/media/ in the archive
moving this bug from the mab3.6 list to the mab4.0 list since 3.6.x is EOL and bug is confirmed in 4.0.x and 4.1.x releases.
*** Bug 70501 has been marked as a duplicate of this bug. ***
*** Bug 70616 has been marked as a duplicate of this bug. ***
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
A college has just experienced a similar problem three times in the last week, all in the same .ods document. It probably happened during autosaves. The file has about 110 images, a mixture of svm and png. The missing images are represented as "<draw:image xlink:href=""><text:p/>" and the images also disappeared from the Pictures folder. This is with LO 4.1.1.2 running on Windows XP. I have not been able to reproduce the problem.
I just came across this issue with most png images in a docx file, using Writer 4.1.5.1 (Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20). Moving this issue to MAB 4.1 as 4.0 reached its EOL a while ago.
The document in issue in 46547 now makes my LibreOffice write crash.
Summary This bug has been confirmed in several versions on many platforms. Comment 3 gives steps used to reproduce with worse results than reported in description, and comment 5 confirms that those steps work in a different version. Comment 6 reports a problem exchanging .odt documents between systems; comment 12 suggests the problem is with odt rather than autosaving and gives steps to reproduce problems with odt. Comment 14 reports problems with docx files and believes the problem is related to autosave. Comment 22 gives 2 methods of reproducing bugs when changing between odt and docx. Comment 23 reports problems with JPEG files becoming empty 8 byte png files and suggests two ideas for solutions. Comment 28 reports problems with ods files as well.
*** Bug 74748 has been marked as a duplicate of this bug. ***
still reproducible under Win7x64 using LibO 4.2.3.3 and 4.3.0.0.alpha1+ Build ID: a1dd961c3093f5f7624e4d1f2240e9120fd13f23 TinderBox: Win-x86@39, Branch:master, Time: 2014-05-06_11:47:48 moving to mab4.2 list since 4.1.x is END OF LIFE
As a professional engineer I write many reports and most have the need for images. A picture is worth .... Because of this persistent bug I and many of my colleagues have given up using LO. I am an advocate of open source and I am keenly disappointed that this major bug has not been even allocated to anyone, let alone resolved. Like many things a bug often produces illogical results that manifest themselves differently in different circumstances. The only way I have found to make LO probably produce a report with images is to have all images saved somewhere, together with a decent picture viewer, and then to write the text leaving sufficient space on a page to accomodate the images later, but not in their correct position of course. Once all the text is in place and I have a saved docx then I re-open and insert each picture in its appropriate place, only ever moving forward in the document and ensuring the picture does not cause leaps from page to page. Fortunately the default wrap aids this process. Also make sure any page headings, footers, numbering and the like are done before putting in any images.. Then export ASAP as a pdf, which seems pretty reliable, certainly before you save... As you may imagine this process is pretty tiresome and a degree stressful. If I need to make further modifications then I use the Serif PagePlus publication software as that allows import of pdfs and subsequent re-export as pdf. From my experiences any deviation or similar that causes some significant structural change in the document seems to create a finite probability of one or more images being lost. I am not convinced this is just an autosave problem because of evidence without it. It is perhaps a possibility however that on occasion autosave does make changes, but it may be more likely that the damage is done already. But because the affected pages were not being visibly present it was not noticed that going back a bit and re-editing actually caused the problem. It is also likely that there is more than one error. Just to add to the story this 'image leak' problem occurs also when I am using a doc or an odt file. Sometimes it does not leak, but in the next hour my hopes are again dashed. I have never seen it happen on a one page doc with one image. Apologies for the lengthy message. I have really tried to use LO but my patience is wearing mighty thin. Please, please do something.
This explanation hit the nail on the head. I agree and have been steering people like myself who use images in their docs away from LO for this very reason. It simply can’t be trusted. And like this person stated, IMMEDIATELY exporting to a PDF is the only way to ensure the desired result … but then no more editing without starting over at the beginning. (As a note, some functions in Tables have similar inconsistencies. I’ve written about this before, but had less than desirable results.) I do hope a copy of this note goes to every officer in the LO organization. Sadly. Otherwise LO is very good. From: bugzilla-daemon@freedesktop.org Sent: Thursday, May 8, 2014 3:46 PM To: Croil Hunter Comment # 34 on bug 52226 from colin.mercer@botley.com As a professional engineer I write many reports and most have the need for images. A picture is worth .... Because of this persistent bug I and many of my colleagues have given up using LO. I am an advocate of open source and I am keenly disappointed that this major bug has not been even allocated to anyone, let alone resolved. Like many things a bug often produces illogical results that manifest themselves differently in different circumstances. The only way I have found to make LO probably produce a report with images is to have all images saved somewhere, together with a decent picture viewer, and then to write the text leaving sufficient space on a page to accomodate the images later, but not in their correct position of course. Once all the text is in place and I have a saved docx then I re-open and insert each picture in its appropriate place, only ever moving forward in the document and ensuring the picture does not cause leaps from page to page. Fortunately the default wrap aids this process. Also make sure any page headings, footers, numbering and the like are done before putting in any images.. Then export ASAP as a pdf, which seems pretty reliable, certainly before you save... As you may imagine this process is pretty tiresome and a degree stressful. If I need to make further modifications then I use the Serif PagePlus publication software as that allows import of pdfs and subsequent re-export as pdf. From my experiences any deviation or similar that causes some significant structural change in the document seems to create a finite probability of one or more images being lost. I am not convinced this is just an autosave problem because of evidence without it. It is perhaps a possibility however that on occasion autosave does make changes, but it may be more likely that the damage is done already. But because the affected pages were not being visibly present it was not noticed that going back a bit and re-editing actually caused the problem. It is also likely that there is more than one error. Just to add to the story this 'image leak' problem occurs also when I am using a doc or an odt file. Sometimes it does not leak, but in the next hour my hopes are again dashed. I have never seen it happen on a one page doc with one image. Apologies for the lengthy message. I have really tried to use LO but my patience is wearing mighty thin. Please, please do something. You are receiving this mail because: You are on the CC list for the bug.
FWIW there's a reasonable chance this is fixed in 4-2-5/4.3.0
I am sad to report that with the latest version downloaded yesterday that the problem with images disappearing is still present. I have tried using links instead to embedding images but with the same result. After saving when I come back and reopen my presentation the link shows but does not display a picture. If I duplicate the slide the image link works and the picture displays. When I close and return the link may or may not work. Or maybe some other link does not work. It is random. So- embedded images disappear at random. Linked images disappear at random. I am sad. I will have to use the product from Redmond Washington to get my work done. Running on Windows 8.1 will presently try on Opensuse and see if the results are better. If there is any change in the behavior I will post a note here.
Hi Bryan Which version exactly did you test this on? Cheers
Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8 is what is on my laptop. I just now started L.O. and opened my presentation. Once again most of the links display pictures but some do not. The ones that do not display are different than the ones that did not display when I last opened the presentation. When I first started trying to build a presentation I embedded pictures only to have the pictures disappear entirely. With links at least the link info is there and I can duplicate the slide and have it work until the next time I save. then it is random as to what works and what does not the next time I open the presentation.
Thanks Bryan. We will be able to test this with 4.2.5 really soon an check if Caolán was right. Caolán, can we have more details about your assumption?
Following https://bugs.freedesktop.org/show_bug.cgi?id=63059#c0 and using https://bugs.freedesktop.org/attachment.cgi?id=77355 I still reproduce the problem with LO 4.2.5.2. To reproduce: 1. open the attached document 2. change it (add a space) 3. save it (as ODT) 4. save as DOCX - WITHOUT CHANGING 5. close the document 6. open the DOCX version: images are missing
(In reply to comment #41) > Following https://bugs.freedesktop.org/show_bug.cgi?id=63059#c0 and using > https://bugs.freedesktop.org/attachment.cgi?id=77355 I still reproduce the > problem with LO 4.2.5.2. Simple to reproduce - also with 4.3.0.2 thanks
Useful comment on role of autosave https://bugs.freedesktop.org/show_bug.cgi?id=46447#c85 Comment with summary of some of the cases https://bugs.freedesktop.org/show_bug.cgi?id=52226#c31 I've seen the problem recently with a writer document and a presentation. Not too complicated, both losing one of the images while editing. I've spend time and time to try to reproduce. Not.. As I've written somewhere else in one of the many occurrences of this problem: Knowing that there are various in memory copies of a document, and in Impress maybe related to various views (side panel, normal view, slide sorter, ..) it may be well possible that there is a problem in synchronising those copies. This is supported by some other comments too. This will help to _not_ reproduce the problem ;) ... but alas neither is a guaranty that it won't happen, nor does it help as a reliable solution to do reproduce it..
hmm, my comment 43 was meant for bug 47148
I can reproduce #41 so I will fix that
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dd5caac62083f7162d83319284df68ee83e3777 Resolves: fdo#52226 swap in graphics on .docx and .rtf export The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e580f3f53ae2de086a08c8ba1958b67874eb9c5 Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So, the reproducible one is fixed. The xlxs I cannot reproduce, but the speculative fix might resolve that if someone is able to reliably reproduce it for testing purposes
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b11f8b75b1ee6da439c3cd7892990b601e03d83&h=libreoffice-4-2 Resolves: fdo#52226 swap in graphics on .docx and .rtf export It will be available in LibreOffice 4.2.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b0282d868b418b4ecdb19cbb633c9399ac84161b&h=libreoffice-4-2 Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage It will be available in LibreOffice 4.2.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd6f03d6f9ceea88e486788b09606c1efcaa4f1f&h=libreoffice-4-3 Related: fdo#52226 ensure graphics are swapped in on DrawingML::WriteImage It will be available in LibreOffice 4.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a90c1bbb74b4dd13b8b3879740ad596a4cedd69a&h=libreoffice-4-3-0 Resolves: fdo#52226 swap in graphics on .docx and .rtf export It will be available already in LibreOffice 4.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=41fde63b3ec4da0a4a6636105dd7b65fdfc7ad44&h=libreoffice-4-3 Resolves: fdo#52226 swap in graphics on .docx and .rtf export It will be available in LibreOffice 4.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Coalan, would you please take a look at Bug 46447 which looks a similar loss of image issue related to auto-save in Impress? the current fix for Bug 52226 had no effect on it, but I wonder if these 2 issues are somewhat related and fixable in a similar way.
*** Bug 81739 has been marked as a duplicate of this bug. ***
@Coalan: I wish to thank you for your work on this bug. I haven't had the occasion to test this yet, but do so as soon as possible. Out of curiority: Can you explain in a few words what that bug was about and maybe a bit about the magic you did to solve it? Thanks again!
Created attachment 104978 [details] screenshot: reproduced in 4.3.1.1 Hi all, This issue is not fixed. Today I reproduce in version 4.3.1.1 Win7, when I was trying to translate the LibreOffice 4.2 Guide in Writer: https://wiki.documentfoundation.org/images/0/0f/GS42-GettingStartedLO.odt It seems images lost at the time when LO is saving auto-recovery info while you are editing the file *at the same time*. Set auto-recovery intevel to 1 minute to observe the lost of images (as I said, you have to keep editing when LO is auto-saving.) The patch is surely included in version 4.3.1.1, as it was build on 07-Aug-2014 11:20. So the patch may not solve the problem. Thanks!
By the way, I do not reproduce in any way in version 4.1.6.2 release. In 4.3.1.1 it's very easy to reproduce. It blocks users from editing files with many images in it. Seems like a regression in 4.3. Should a new bug report be filed?
please do not reopen bugs, file new ones, especially in a case like this where there multiple problems and a huge number of comments
@Kevin if you open a new report please put the link to this one under "See Also"
(In reply to comment #59) > please do not reopen bugs, file new ones, especially in a case like this > where there multiple problems and a huge number of comments I filed bug 82953 to report the problem I reproduce in 4.3.1.1.