>> Feature Request Summary: Can share images twice using email >> Description of feature, or problem to be solved I'm sharing my images directly to flickr using the share by email using my xxxx@photos.flickr.com email. The first pictures works properly but subsequent shares won't work, I'll need to restart the device to be able to send. 1)choose a picture in the gallery 2)click the share button 3)choose email 4) enter email + subject +text 5)send -hear nice notification sound 6) do 1,2,3 Email app start shows the compose window( doh I'm too tied to Thunderbird vocabulary). The images is not attached and you can't really share the image. Filling into Email as it's the last gaia app I'm seeing.

Can you provide a logcat? (See https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for tips on that.) Also, can you indicate the domain/server type of the email account you're using? The two main options are that we're experiencing a problem processing the Blob, or we haven't started yet because we're backlogged on the job-op. For example, because we're still busy appending the message to your sent folder. Which is where the domain/server type comes in; if it's gmail, we aren't trying to do that. For all other account types, we do have to append the message to the sent folder, and that can take just as long as initially sending the message.

(In reply to Andrew Sutherland [:asuth] from comment #1) > Can you provide a logcat? (See > https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for tips on that.) will do tomorrow. > Also, can you indicate the domain/server type of the email account you're > using? Imap/free.fr (zimbra based) > The two main options are that we're experiencing a problem processing the > Blob, or we haven't started yet because we're backlogged on the job-op. For > example, because we're still busy appending the message to your sent folder. > Which is where the domain/server type comes in; if it's gmail, we aren't > trying to do that. For all other account types, we do have to append the > message to the sent folder, and that can take just as long as initially > sending the message.

Adb logcat per request.

Device : Z3C BuildID : 497fe3f9 Domain : Free.fr Protocol: SMPT+IMAP Network was working as I uploaded https://www.flickr.com/photos/lhirlimann/20525191772/in/dateposted/ in the first place.

The log contains the following that is likely the problem: 08-13 17:30:34.234 I/GeckoDump( 1810): ERR: Logic fail: Error: Problem handling message type: composeBegun TypeError: this.attachmentsContainer is undefined 08-13 17:30:34.234 I/GeckoDump( 1810): .renderAttachments@app://email.gaiamobile.org/js/cards/compose.js:544:21 08-13 17:30:34.234 I/GeckoDump( 1810): .addAttachmentsSubjectToSizeLimits@app://email.gaiamobile.org/js/cards/compose.js:539:21 08-13 17:30:34.234 I/GeckoDump( 1810): activityComposeR/<.onComposer@app://email.gaiamobile.org/js/config.js:1723:21 08-13 17:30:34.234 I/GeckoDump( 1810): .postInsert/</</this.composer<@app://email.gaiamobile.org/js/cards/compose.js:223:37 08-13 17:30:34.234 I/GeckoDump( 1810): MailAPI.prototype._recv_composeBegun@app://email.gaiamobile.org/js/ext/main-frame-setup.js:2616:17 08-13 17:30:34.234 I/GeckoDump( 1810): ma__processMessage@app://email.gaiamobile.org/js/ext/main-frame-setup.js:1935:28 08-13 17:30:34.234 I/GeckoDump( 1810): ma___bridgeReceive@app://email.gaiamobile.org/js/ext/main-frame-setup.js:1925:17 08-13 17:30:34.234 I/GeckoDump( 1810): bridge.process@app://email.gaiamobile.org/js/ext/main-frame-setup.js:3842:17 08-13 17:30:34.234 I/GeckoDump( 1810): register/action@app://email.gaiamobile.org/js/ext/main-frame-setup.js:2811:17 08-13 17:30:34.234 I/GeckoDump( 1810): dispatchToListener@app://email.gaiamobile.org/js/ext/main-frame-setup.js:2845:17 After that, the log does show us properly attaching the attachment. It just seems to be the UI that's broken. If you leave the compose window and save the draft and return, you should see your attachment listed. Since attachmentsContainer is initialized as part of the mixin at construction time, it seems like this is another instance of platform bug 1176829 involving custom elements and we should dupe to that. Since that has to do, I think with the email app not being visible when processing the activity, the workaround is likely to use the "pick" mechanism wherein you trigger the attachment process from within the compose window by hitting the paperclip icon. :jrburke, needinfoing you to confirm the dupe. It seems reasonably clear cut to me, but I want to avoid mis-duping and I'm not 100% on the mix-in control flow.

I could not reproduce this on the very latest flame-kk or the on Aries with Build ID 20150810211816. It could be subject to other factors though, because I can still reproduce bug 1176829. The log trace in comment 8 definitely fits the expected profile for bug 1176829. In this case, postInsert() is where the failure happens (something called by postInsert()), where in bug 1176829 it was onArgs, however, both of those functions are called as part of cards.pushCard(), following the construction of the custom element. The construction of the element should call the createdCallback(), which grabs the reference to `this.attachmentsContainer`. After element construction, onArgs is called, then postInsert() after some other work is done in pushCard. So I am going to dupe this bug to bug 1176829. It would be good to hear from :Usul if trying after a new Aries system update if it still occurs. Not critical, so not setting ni, just if it happens to be noticed, great. I still suspect fixing bug 1176829 will avoid any possibility of this type of error where something set up in the createdCallback is not available.