Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox: Email content sometimes lost when sending #31

Closed
adam-p opened this issue Oct 1, 2012 · 3 comments
Closed

Firefox: Email content sometimes lost when sending #31

adam-p opened this issue Oct 1, 2012 · 3 comments

Comments

@adam-p
Copy link
Owner

adam-p commented Oct 1, 2012

Reproduction, maybe:

  1. In Firefox, in Gmail. (Not sure about other webmail clients. Doesn't seem to happen in Chrome.)
  2. Have a signature (not sure if that's necessary).
  3. Set yourself as the recipient for the email. Put whatever in the subject.
  4. Type some trivial Markdown in the body. Without moving the cursor or anything, hit the Markdown Here hotkey. You should see that the body of the email is oddly large and the sig suddenly has a serif font.
  5. Send the email.
  6. View the sent email. It has a sig but is missing the MD body you typed.

When viewing the DOM after the rendering, it appears that the markdown-here-wrapper is ending up as a direct child of the html element, instead of the body element -- but the sig is staying in the body.

I don't have any other info or insight into this right now, but I'll look into it soon. It's very bad.

@adam-p
Copy link
Owner Author

adam-p commented Oct 3, 2012

More info:

Affected clients

  • Firefox with Gmail (but not Yahoo or Hotmail/Outlook, and not Chrome).
  • Thunderbird
  • Postbox (I think)
  • Not tested in others

What's happening

If the user tabs into the compose body from the subject box, then the activeElement of the compose iframe will be the html element. This is in contrast to if the user clicks the mouse in the compose body, which causes the body element to be the activeElement.

If the user then uses the Markdown Here hotkey, this causes our findFocusedElem() to return the the html element, and that sets the breakage in motion.

Workaround

Click in the body at least once before Markdown Toggling. Or right-click (use the Markdown Toggle context menu item, for example).

Fixing it

My best/only idea so far is something like:

if (focusedElem instanceof HTMLHtmlElement) {
  focusedElem = focusedElem.ownerDocument.body;
}

This feels kinda dirty and/or hacky and/or special-case-y. But I don't know another way of finding the focus (side note: querySelector(':focus') doesn't work).

I'll probably use that fix. But I'll think about it until tomorrow. If anyone has another idea, please let me know.

@adam-p
Copy link
Owner Author

adam-p commented Oct 4, 2012

There seems to already be a bug filed with Mozilla about this behaviour:
https://bugzilla.mozilla.org/show_bug.cgi?id=740813

adam-p added a commit that referenced this issue Oct 4, 2012
@adam-p
Copy link
Owner Author

adam-p commented Oct 9, 2012

Fixed in version 2.6.2 (which should clear Mozilla review in a week).

@adam-p adam-p closed this as completed Oct 9, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant