Open Bug 557708 Opened 15 years ago Updated 1 year ago

Drag and drop of images from Firefox to Thunderbird as attachment results in BMP conversion, fails when sending

Categories

(Core :: Widget: Win32, defect, P5)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows 7
Type:
defect

Tracking

()

People

(Reporter: rsx11m.pub, Unassigned, Mentored)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: good-first-bug, Whiteboard: [lang=c++][privacy][tpi:+])

Attachments

(2 files, 3 obsolete files)

bug557708-v4.patch
(deleted), patch
jimm
: review-
Details | Diff | Splinter Review
Bug 557708 - Prefer DropFile* to DropImage for CF_HDROP. r?jmathies@mozilla.com
(deleted), text/x-phabricator-request
Details
Using Firefox 3.0.19 and earlier, when viewing an image in the browser (right-click, View Image), then drag-and-drop it into the attachment pane, would result in Thunderbird downloading the original file from the server. Doing the same from 3.6.3 on Windows, a static copy is attached in bulky BMP format (thus, without any compression whatsoever). This is also the case for drag-and-drop from Firefox 3.6.3 to SeaMonkey 2.1a1pre, and from SeaMonkey 2.1a1pre to Thunderbird 3.0.4. Drag-and-drop from browser to composition windows within SeaMonkey 2.1a1pre results in the desired behavior of the original being attached. Also, drag-and-drop into an HTML composition produces a link to the original and "attach this image" set by default, thus also downloading the original. If the behavior was changed on purpose and for a good reason, at least a more mail-friendly PNG format should be chosen, or the clipboard.paste_image_type preference observed. I'm filing this for MailNews Core first, but this may need to go into Core Widgets: Win32 if it's a general clipboard issue. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100406 SeaMonkey/2.1a1pre
I'm unable to reproduce this on Linux, thus it appears to be primarily an issue with the Windows widgets. Since no comments from MailNews came in, I'm moving this bug respectively.
Component: Composition → Widget: Win32
Product: MailNews Core → Core
QA Contact: composition → win32
I've retested this with more recent builds and see a different behavior now on builds from 5.0 and 6.0: > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110703 SeaMonkey/2.3a2 Drag and drop of an image from the 6.0 browser into the 5.0 attachment pane still creates a random BMP attachment and even reports the correct size when attaching, but upon sending or saving as draft, I'm now getting "Unable to open temporary file [attachment location]. Check your 'Temporary Directory' setting." The behavior between Firefox 3.6.18 and Thunderbird 5.0 is unchanged, thus the temporary file created by the browser apparently is now deleted immediately in Gecko 6.0 after the reference is passed on to the mail/news application.
Severity: normal → major
OS: Windows XP → Windows 7
Summary: Drag and drop of images from Firefox to Thunderbird as attachment results in BMP conversion → Drag and drop of images from Firefox to Thunderbird as attachment results in BMP conversion, fails when sending
Assignee: nobody → netzen
This page describes some image clipboard formats: msdn.microsoft.com/en-us/library/aa359736(v=vs.85).aspx In particular we could support when we "Copy Image" we add to the clipboard: CFSTR_MIME_X_PNG (TEXT("image/x-png")) We would then need to post a different task for Thunderbird to use this new clipboard format instead though.
This just happened to me, when I dragged a 64 kB jpg from Firefox 20.0.1 into an email in Thunderbird 21.0b1 which produced a 2.4MB email due to having converted the image into bmp. I don't remember having had this problem before, but clearly whatever the issue is, it's still there! As the OP says, it would probably be a great idea to start with to default to PNG24 instead of defaulting to BMP. But the most ideal would of course be if the original compression could be kept, if that is possible. This is the image that I dragged from FF into TB, so that you can test with the same conditions: http://images3.wikia.nocookie.net/__cb20121116012752/disney/images/d/d0/Ponyo004.jpg
I'm not sure if the original image format is still available (it would be if a reference is passed over the clipboard rather than the image bitmap data itself, but then you may run into problems with Thunderbird having to download the data on its own, potentially not being aware of the correct context that Firefox had). As far as I know, pixel data is transferred as "Device Independent Bitmap" on Windows, which corresponds to the BMP file format. However, when pasting an image into the editor, it will be converted to either PNG (default) or JPEG, depending on the setting of the clipboard.paste_image_type preference, to compress the image.
Thanks for the explanation. My clipboard.paste_image_type is 1 (which means prefering PNG > JPG > GIF). But here are three use-cases that result in three different image types: (1) When I copy-and-paste a selection of bitmap data from an image editor, Thunderbird does compress it in the PNG format. So the setting works correctly for pasting pure bitmap data from the clipboard. (2) But when I drag-and-drop the image from FF into TB, it is inserted as BMP. No compression algorithm is selected. (3) But, interestingly, when I right-click and copy that same image in FF, and then paste in TB, it attaches the original file with the orginal filename and compression. What happens is it creates an image with the image URL, an "Attach this image" turned on. So it seems there's a difference between drag-and-drop and copy-and-paste. Only drag-and-drop has this issue: it's as if the selection of a compression algorithm is skipped in this case. I guess the question is: what exactly happens when dropping an image into the Editor? I doesn't "copy-paste" the original image (as in (3)), and it doesn't paste pure bitmap data (as in (1)). I think I understand that it doesn't do (3), but it should at least do (1) then. (2) should never happen :)
Interestingly, when I drag-drop an image together with some text surrounding it, it copies the original HTML and so the original image is attached (as in case (3)). The issue only occurs when only the image itself is dragged and dropped.
(In reply to Joris Debonnet from comment #6) > (3) But, interestingly, when I right-click and copy that same image in FF, > and then paste in TB, it attaches the original file with the orginal > filename and compression. What happens is it creates an image with the image > URL, an "Attach this image" turned on. This version actually copy-pastes HTML code with an <img src="http://..."> reference to the original location, then Thunderbird downloads and attaches it. No recoding is performed in this way. Copy-pasting in case (1) transfers the actual pixel data, hence the DIB -> PNG recoding. My initial observation for opening this bug was recoding of the image to BMP when drag-and-drop into the attachment pane (i.e., not into the message itself) was performed, but maybe case (2) runs into the same issue for drag-and-drop into the message itself.
Aha, I see. I was wondering whether I should open a new bug, but I guess it sounds like it's the same: dropping bitmap data into the message or attachment pane works as expected, but dropping an actual image from a webpage in Firefox does not. Interestingly, the issue only occurs as discussed when dragging from Firefox. When I drag-drop from IE8/9/10, it attaches the image from its cache (good!), and when I drag-drop from Google Chrome it works when dragging into the attachment pane (with a bad filename and no file size info, but it works), though it fails miserably when dragging into the message (it inserts a string of Asian characters instead). In any case, Firefox seems to be the only one that drags that bitmap format around with no better alternative attached. Chrome and IE try delivering the original file before they would default to delivering the bitmap data. (I may be wording this in a strange way, but you get what I mean) Regardless, Thunderbird should handle that 'dropped' bitmap data the same way it would handle 'pasted' bitmap data. I just mentioned the above because perhaps it's Firefox that does something really weird with the data, confusing Thunderbird into believing it's already in a good format. Or something.
Similar report in bug 871873 - dragging JPG image into TB compose window inserts as inline BMP.
Blocks: 871873
See bug 871873 comment #7 and following for more analysis. It appears that this bug here is caused at the source application, whereas the other bug reflects a change in drag-and-drop behavior on the receiving end.
Blocks: attach-paradigm-fail
This is a repost from a different thread. The information is relative to this issue and <A HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=871873">bug 871873</A>, so I'm adding it to both these threads: Firefox 24 Steps to reproduce: drag & drop From Firefox, drag an image from a web page to a Windows Explorer window Doing so copies the selected image to the Windows Explorer folder, but ALSO creates a .BMP bitmap copy in C:\Documents and Settings\UserName\Local Settings\Temp So many of the comments below describe similar or the same behavior, dragging-dropping from Firefox to Thunderbird, however it should be helpful to know it also occurs by dragging from Firefox to Windows Explorer (and the Desktop) Shout-out of thanks to @rsx11m Until this is corrected, I've just had to make a .BATch file to DEL them
Assignee: netzen → nobody
Yet another flavor of this bug: Using drag-and-drop of an image from the website from Firefox (24 ESR) into a SeaMonkey build (2.27a2) creates a data: URI which is incomplete and lacks the type of the image ("data:<junk>;base64,<encoding>" where <junk> may be empty or an arbitrary string). When saving the message as draft, it gets attached as "text/plain" which doesn't make much sense. No messages in the error console. This was tested on Windows 7.
(In reply to Brian R. Bondy [:bbondy] from comment #3) > In particular we could support when we "Copy Image" we add to the clipboard: > CFSTR_MIME_X_PNG (TEXT("image/x-png")) > We would then need to post a different [bug] for Thunderbird to use this new > clipboard format instead though. If I understand informed comment 3 correctly, this bug actually starts in FF which does not preserve enough clipboard data to allow pasting in a better format than bmp (or even the original image format). Does FF still have this lack? (clipboard inspection of copied-from-FF image.png/jpg needed) If yes, do we have a FF bug for that?
Mentor: jmathies, tabraldes, netzen
Whiteboard: [good first bug][lang=c++][privacy]
Hello! Could someone please guide me along what needs to be done here? I'm new, and looking for a bug to tackle! Thank you!
Ni, Neil - sorry for not getting back to you sooner, are you still interested in this bug?
Flags: needinfo?(neilkakkar)
Hello, I would like to give it a try. It would be my first contribution ever, so I will probably need a special guidance from you mentor guys. :)
Hey Mike! Likewise. I have my exams right now, I'd need 10 days before I can work on this. Thanks!
Flags: needinfo?(neilkakkar)
Hey Mike, Is the bug resolved yet? If not, I would like to try and fix this bug. Although I'm a new contributor, I am prepared to work on this, for however long it takes.
Flags: needinfo?(netzen)
Thanks Sreekar, I assigned the bug to you. I haven't worked on this code in a while but some good starting points would be to set breakpoints in `widget/windows/nsClipboard.cpp`, `widget/windows/nsImageClipboard.cpp`, and `widget/windows/nsDataObj.cpp` to learn the code around there.
Assignee: nobody → cs13b1008
Flags: needinfo?(netzen)
Just in case nobody has tested other applications: This also happens in Skype - it can't transfer image if I drag-n-drop it from Firefox to Skype Also, bug 1191462 states that conversion to BMP is unwanted. Somehow, I agree with that.
Blocks: 1191462
Sreekar, are you still working on this?
Flags: needinfo?(cs13b1008)
Variation on this bug or other; Windows7, Open a BMP file using Windows Photo Viewer (the default), copy image. Paste image into compose window of Thunderbird (now using 38.5.1) along with some other text. Send it. It will look fine in Thunderbird but not at all in e.g. Outlook or Outlook web client. The problem is that the encoded attachment is text/plain and apparently at least Outlook fails to view this inline attachment using "<img src="cid:part1.07030500.08000004@precisebiometrics.com" alt=""> while Thunderbird seems to bypass the faulty content-type. Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: base64 Content-ID: <part1.07030500.08000004@precisebiometrics.com>
(In reply to rsx11m from comment #22) > Sreekar, are you still working on this? Apparently not, thus unassigning...
Assignee: cs13b1008 → nobody
Flags: needinfo?(cs13b1008)
Mentor: netzen, timabraldes
Severity: major → normal
Priority: -- → P5
Whiteboard: [good first bug][lang=c++][privacy] → [good first bug][lang=c++][privacy][tpi:+]
Hello, I would like to work on this issue. Could you please assign it to me ? Thanks,
Hello, I have reproduced the case described using firefox nighly build on my machine (Windows 10) and Thunderbird 45. When i drag & drop an image loaded in FF to Thunderbird, it creates a "big" BMP file. In debug mode the call stack shows: nsImageToClipboard::CreateFromImage line 127 is called by: nsDataObj::GetDib line 853 if i understand well the code: nsresult nsImageToClipboard::CreateFromImage ( imgIContainer* inImage, HANDLE* outBitmap ) always create BMP files. Should the logic be changed in nsDataObj::GetDib ? Thanks,
Hello, in: nsImageToClipboard::CreateFromImage ( imgIContainer* inImage, HANDLE* outBitmap ) line 146 seems to force the creation of a bitmap file: nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv); Should this be changed or made more flexible ? Thanks,
Hello, just as a test, a have replaced the line : nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv); by nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/jpeg", &rv); I am not claiming this is the solution but with this, locally built FF was able, withthe described Drag and Drop, to create an email attachment with a JPEG instead a BMP. I would like to have your opinion on this in order to move forward for this issue. Thanks,
Flags: needinfo?(jmathies)
Hello, This is in fact quite complex: We can have the BMP built through the nsImageToClipboard::CreateFromImage called by nsDataObj::GetDib method but there is also another code path leading to a temporary BMP file: nsDataObj::DropImage This method also calls nsImageToClipboard::CreateFromImage and tries to dump the generated BMP file into the temp folder. I would like to get some help / advise on how to fix this. Thanks,
Attached patch bug557708-v1.patch (obsolete) (deleted) — — Splinter Review
Hello, This is a first patch proposal: I tried to get rid of the BMP generation and amended the GetDib method to use the image flavor in order to handle JPEG/PNG/GIF/BMP formats. I have unit tested this code with TB 45.5.1 on Windows 10. I have noticed that the attachments remain with they original format but that TB states it is a "portion of embedded message". Thanks,
Attachment #8822033 - Flags: review?(jmathies)
Wayne, Jörg, can you pls ensure or cc others to ensure that Jeanluc gets enough assistance/attention/direction/reviews here so that we can succeed to take this promising patch through. There's also an assigned mentor, Jim Mathies [:jimm], thank you for mentoring and please come forward ;) Tia.
Assignee: nobody → jeanluc.bonnafoux
Status: NEW → ASSIGNED
This is M-C code in widget/windows. TB's knowledge (and review permission) doesn't reach there. I can tell you however, that the patch contains a lot of trailing spaces that the reviewer will complain about ;-)
Hello, I am happy to remove the trailing spaces. Would you mind giving me one example in the patch i have submitted ? Thanks,
Click on "Splinter Review" above and you'll see them all. Surely you can also detect them in the patch you uploaded using the editor of your choice. In Notepad++ on Windows I search for the regular expression | $| (of course without the |, so space dollar) to find spaces at the end of the line.
Attached patch bug557708-v2.patch (obsolete) (deleted) — — Splinter Review
Hello, This is a second patch proposal: I tried to get rid of the BMP generation and amended the GetDib method to use the image flavor in order to handle JPEG/PNG/GIF/BMP formats. I have removed all trailing spaces in the 3 files i have amended. I have unit tested this code with TB 45.5.1 on Windows 10. I have noticed that the attachments remain with they original format but that TB states it is a "portion of embedded message". Thanks,
Attachment #8822033 - Attachment is obsolete: true
Attachment #8822033 - Flags: review?(jmathies)
Attachment #8822064 - Flags: review?(jmathies)
I think you misunderstood. The idea was not to remove all trailing spaces in the files you touch, since that generates many changes, but not to add new trailing spaces with your patch. If you have a look at your now superseded first patch, there were some trailing spaces added where there weren't any before and also where you made real changes. Applying "boy scout rules" (that is, leaving the camp site cleaner than you found it) is appreciated by some reviewers but not all, since it increases the changes to be reviewed.
Hello Jorg, We are right, i had misunderstood the comment. I was under the impression that it was mandatory to remove all trailing spaces in files (.h / .cpp) before submitting a patch. Would you like me to revert my V2 patch and prepare a V3 removing trailing spaces only for code i have amended ? Thanks,
Yes. Best use v1 to start. You can actually remove trailing spaces directly in the patch file in the lines being added, the ones which have a +. Editing patches can be tricky, you need to remember that the first column is one of - + or space. Since you have - +(space space) you will need to refresh straight after applying the modified patch since this group will be removed upon refresh. Do check the patch before resubmitting it.
Attached patch bug557708-v3.patch (obsolete) (deleted) — — Splinter Review
Amended V1 patch proposal to remove trailing spaces only on code i have amended. Thanks
Attachment #8822064 - Attachment is obsolete: true
Attachment #8822064 - Flags: review?(jmathies)
Attachment #8822073 - Flags: review?(jmathies)
Comment on attachment 8822073 [details] [diff] [review] bug557708-v3.patch Review of attachment 8822073 [details] [diff] [review]: ----------------------------------------------------------------- Sorry to be so picky. Only lines that were changed should be in the patch. ::: widget/windows/nsDataObj.cpp @@ +1450,5 @@ > nsresult rv; > if (!mCachedTempFile) { > uint32_t len = 0; > nsCOMPtr<nsISupports> genericDataWrapper; > + What's the change here? You edited the patch, but didn't apply and refresh it since that would have removed this "non-change".
Hello, No problem. Could you please provide me a link to a manual that would explain how to perform the "apply and refresh" actions described in your comment ? Thanks,
Hmm, that really depends on your workflow and how you created the patch in the first place. I'm using mercurial queues (which are deprecated, so I shouldn't advertise this), and there the commands are: hg qnew, hg qpop, hg qpush and hg qref. Some use TortoiseHg. There are many ways to skin a cat here, but having changes in your patch which aren't real is not well regarded ;-)
Attached patch bug557708-v4.patch (deleted) — — Splinter Review
Proposed patch version 4, regenerated patch file from Mercurial command, trying to get rid of trailing spaces.
Attachment #8822073 - Attachment is obsolete: true
Attachment #8822073 - Flags: review?(jmathies)
Attachment #8822080 - Flags: review?(jmathies)
Flags: needinfo?(jmathies)
Hello, Could you please tell me if the proposed patch is a good candidate to solve this issue ? Thanks,
Flags: needinfo?(acelists)
Thanks for looking into this. Sorry, I'm not on Windows to be able to test the patch. As said, we will need gecko-core people to look at the proposal. Looks like you have already found a good candidate.
Flags: needinfo?(acelists)
Hello, Who should i contact in order to get some feedback on this patch proposal ? Thanks,
(In reply to jbonnafo from comment #47) > Who should i contact in order to get some feedback on this patch proposal ? jimm just hasn't reviewed it yet. Unless he has someone else in mind
Flags: needinfo?(jmathies)
Comment on attachment 8822080 [details] [diff] [review] bug557708-v4.patch Review of attachment 8822080 [details] [diff] [review]: ----------------------------------------------------------------- minor nits here. I need to do some manual testing and push to try as well. ::: widget/windows/nsDataObj.cpp @@ +1367,5 @@ > m_enumFE->Reset(); > while (NOERROR == m_enumFE->Next(1, &fe, &count) > && dfInx < mDataFlavors.Length()) { > + if (mDataFlavors[dfInx].EqualsLiteral(kNativeImageMime) || > + mDataFlavors[dfInx].EqualsLiteral(kFileMime)) You should remove the kFileMime check below this, it's redundant. ::: widget/windows/nsImageClipboard.cpp @@ +162,5 @@ > + encoderCID.Append(bmpString); > + } > + > + nsCOMPtr<imgIEncoder> encoder = do_CreateInstance(encoderCID.get(), &rv); > + //nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv); nit, remove this code.
Attachment #8822080 - Flags: review?(jmathies) → review-
Flags: needinfo?(jmathies)
also if you wouldn't mind, please merge this with tip. My fault in that the review took so long. unfortunately tb patches fall to the bottom of the todo list these days.
Flags: needinfo?(jeanluc.bonnafoux)
Hello, Thanks for the code review, i will amend files accordingly a submit a new proposal. Thanks,
"please merge this with tip", Could somebody tell me what this means ?
Flags: needinfo?(jeanluc.bonnafoux)
Sure. As the codebase at Mozilla changes quickly, the patch most likely doesn't apply any more, some say "it has bit-rot" or "it bit-rotted". So the patch needs to be rebased on the latest version of the underlying files, which is the "tip" or "default". Sorry about the jargon ;-(
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
jbonnafo has suggested he will look at updating the patch
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Status: REOPENED → ASSIGNED
Keywords: good-first-bug
Whiteboard: [good first bug][lang=c++][privacy][tpi:+] → [lang=c++][privacy][tpi:+]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Assignee: jeanluc.bonnafoux → nobody
Status: ASSIGNED → NEW

Note that copying e.g. https://bug-attachments.documentfoundation.org/attachment.cgi?id=178031 to Windows clipboard uses a temporary JPG file, and dragging it to another application uses a BMP; both they use CF_HDROP clipboard format for the transfer that refers to the temporary file, so there seems to be different code paths here that account for this unfortunate difference.

The actual creation of the temporary BMP in the filesystem happens inside IDataObject::GetData call, with FORMATETC referring to CF_HDROP. So there should be something in the DnD data OLE object implementation if FF that is responsible for that.

The patches from jbonnafo looked to touch related area (even though they were adding unneeded breaks in switch after return statement, and so on).

nsDataObj::GetFile, that gets called for CF_HDROP, iterates through mDataFlavors; and it stops on whatever one of the three types it finds first:

  • application/x-moz-nativeimage -> DropImage
  • application/x-moz-file -> DropFile
  • application/x-moz-file-promise -> DropTempFile

In case of copy to clipboard, mDataFlavors has:

  • text/html
  • text/html
  • text/_moz_htmlinfo
  • text/_moz_htmlcontext
  • application/x-moz-file-promise-url
  • application/x-moz-file-promise-dest-filename
  • application/x-moz-file-promise
  • application/x-moz-file-promise
  • application/x-moz-nativeimage
  • application/x-moz-nativeimage
  • application/x-moz-nativeimage

So in this case, DropTempFile gets called for item 6.

In case of drag-n-drop, it has:

  • text/x-moz-url
  • text/x-moz-url
  • text/x-moz-url
  • text/x-moz-url
  • text/x-moz-url
  • text/x-moz-url
  • text/x-moz-url-data
  • text/x-moz-url-desc
  • application/x-moz-custom-clipdata
  • text/_moz_htmlcontext
  • text/_moz_htmlinfo
  • text/html
  • text/html
  • text/unicode
  • text/plain
  • application/x-moz-nativeimage
  • application/x-moz-nativeimage
  • application/x-moz-nativeimage
  • application/x-moz-file-promise
  • application/x-moz-file-promise
  • application/x-moz-file-promise-url
  • application/x-moz-file-promise-dest-filename

and DropImage gets called for item 15.

A simple fix could be converting the single loop in nsDataObj::GetFile into three separate loops, first one checking for x-moz-file-promise, then for the rest two. That is in case the calls to m_enumFE methods actually do something (I do not see what can they be useful for, actually, but I digress), otherwise one loop could store less preferred index, and keep searching until it finished the loop or found most preferred case, then perform the call corresponding to the found most preferred case.

But I do not know if x-moz-file-promise is actually preferable over x-moz-nativeimage. Is the elements order in mDataFlavors important? Why are there duplicates?

DropImage changes image type to BMP unconditionally, which makes
it undesirable for drag-and-drop operations. Only call it when
the flavor list doesn't have the other two options.

Also remove calls to m_enumFE->Reset and m_enumFE->Next, since
their results are unused in the processing here.

Assignee: nobody → mikekaganski
Status: NEW → ASSIGNED

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Assignee: mikekaganski → nobody
Status: ASSIGNED → NEW
Assignee: nobody → mikekaganski
Mentor: jmathies → davidp99
Severity: normal → S3

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Assignee: mikekaganski → nobody

N-i for the review of the attached patch.

Assignee: nobody → mikekaganski
Flags: needinfo?(davidp99)

The patch itself looks pretty good but we want to settle bug 1765222 first as this makes assumptions that it would guarantee.

Depends on: 1765222
Flags: needinfo?(davidp99)

(In reply to David Parks [:handyman] from comment #64)

The patch itself looks pretty good but we want to settle bug 1765222 first as this makes assumptions that it would guarantee.

You mean the proposed fix for this bug 557708 relies on bug 1765222 being fixed. It's obvious when you think about it; I'm just clarifying what you mean by "this".

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: mikekaganski → nobody

Hello, is this bug still available? If it is, I will look into it, and once I grasp what's involved, I'll ask it to be assigned to me.

Yes this annoying bug is still available on Windows!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: