Firefox GMail stopped working about emacs_chrome

[FrostyX]

I must admit I only really use Edit with Emacs for very basic
composing in Gmail as I already download gmail to my machine for mu4e
;-)

The "problem" is that my work email has 2FA and I have already spent
20+ hours trying to configure mbsync and similar tools to download
my mail but I just couldn't do it.

I am sorry for resurrecting an old, off-topic discussion. But for the record, I finally figured this out and I would like to share a link to my blog post here. Maybe it can help somebody else struggling with the issue.
http://frostyx.cz/posts/synchronize-your-2fa-gmail-with-mbsync

[stanfordcox]

Neglected to mention: Fedora release 32
Worked fine with Fedora release 31: firefox 69.0.1-3, emacs 26.2-2

[dakra]

Do you have chrome/chromium installed and does it work there?

[stanfordcox]

I installed chrome and added edit with emacs extension inside chrome and I see the same behavior:

1. compose area has no blue 'edit' button, right click 'Edit With Emacs' gives an empty emacs buffer
2. hangouts, e.g. works fine: blue 'edit' button when click drops into emacs with text in buffer

[ponimas]

Doesn't work in chrome as well.

Chrome 84.0.4147.89
Ubuntu 18.04
GNU Emacs 28.0.50
edit-server from melpa

[stsquad]

There does seem to have been a change to the way gmail's HTML works. Weirdly I can edit the ext box with the context menu but the text doesn't appear when I complete. A follow up edit however restores the previous text.

[stanfordcox]

<Weirdly...> You're right, I had not noticed that oddity.

[stsquad]

@stanfordcox could you try the latest master and see if the tweak works for you?

[FrostyX]

Hello @stanfordcox,
I am not the OP but thank you very much for the fix, it is very appreciated.

I can confirm that chrome extension from git repository works for me and allows me to edit GMail "textarea". The only minor flaw I found is that for some reason, it opens the Emacs buffer for writing the email text in two of my emacs windows at the same time. It pops a new frame as expected, but it also temporarily changes one window in an existing frame. This happens only for Gmail. The textareas that worked before this fix still works fine.

It's just a minor issue and I don't mind it that much. On the other hand Gmail support is huge!

[stanfordcox]

Much appreciated indeed. Upstream works fine for me with gmail using firefox 83.0

[FrostyX]

Hello @stanfordcox,
I discovered one more issue. I am not sure whether it is a bug or
PEBKAC though.

When I use the standard email markup (with e.g. starting lines with >
for quoting), the text is not inserted into the Gmail area as is but
it is converted to HTML. Even though I have "Plain text mode" selected
in the message options.

My workaround is to write a message in Emacs, pushing it into Gmail
textarea with C-c C-c, clicking on the three vertical dots in the
bottom right of the message window, toggling "Plain text mode" off and
then toggling the "Plain text mode" back on. That reformats the output
to not be rendered as HTML.

[stsquad]

On Sun, 27 Dec 2020 at 11:19, Jakub Kadlčík ***@***.***> wrote: Hello @standfordcox, I discovered one more issue. I am not sure whether it is a bug or PEBKAC though. When I use the standard email markup (with e.g. starting lines with > for quoting), the text is not inserted into the Gmail area as is but it is converted to HTML. Even though I have "Plain text mode" selected in the message options.

This is because even though the Gmail UI says it's plain text it really isn't. It still stores the actual text as HTML so needs the proper escaping.

My workaround is to write a message in Emacs, pushing it into Gmail textarea with C-c C-c, clickin on the three vertical dots in the bottom right of hte message window, toggling "Plain text mode" off and then toggling the "Plain text mode" back on. That reformats the output to not be rendered as HTML.

Another approach as described in the wiki: https://www.emacswiki.org/emacs/Edit_with_Emacs is to use the edit-server-htmlize package: https://github.com/frobtech/edit-server-htmlize And apply those hooks to convert to real plain text and back during the edit. However I can see html2text is now deprecated so perhaps we need a cleaner more modern solution for that. I must admit I only really use Edit with Emacs for very basic composing in Gmail as I already download gmail to my machine for mu4e ;-)

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Alex, homepage http://www.bennee.com/~alex/

[stsquad]

The above comment was done via the gmail interface (and EwE) and this one is via the github UI.

[FrostyX]

And apply those hooks to convert to real plain text and back during the edit.

I will try that, thank you.

I must admit I only really use Edit with Emacs for very basic
composing in Gmail as I already download gmail to my machine for mu4e
;-)

Oh @stsquad, how I would love to.

The "problem" is that my work email has 2FA and I have already spent
20+ hours trying to configure mbsync and similar tools to download
my mail but I just couldn't do it. The most frustrating thing is that
I was able to do it in thunderbird in five minutes, so it is not
impossible.

I don't want to derail the conversation into offtopic here but if you
have any idea how to do so, please, please ping me somewhere.

[stsquad]

@FrostyX I have 2FA for my work GMail as well but I use an app specific password for mbsync and imap. However this will eventually go away (depending on if you've enrolled in the advanced security protection).

Anyway as you say unrelated so I think I shall close this now.

[FrostyX]

@stsquad this might still be worth looking at if it is an easy fix

The only minor flaw I found is that for some reason, it opens the Emacs buffer for writing the email text in two of my emacs windows at the same time. It pops a new frame as expected, but it also temporarily changes one window in an existing frame. This happens only for Gmail.

If it is a more complex issue, then it's IMHO not worth wasting time.

[stsquad]

Can you replicate that with emacs -q because it works for me.

…

On Sun, 27 Dec 2020 at 14:19, Jakub Kadlčík ***@***.***> wrote: @stsquad this might still be worth looking at if it is an easy fix The only minor flaw I found is that for some reason, it opens the Emacs buffer for writing the email text in two of my emacs windows at the same time. It pops a new frame as expected, but it also temporarily changes one window in an existing frame. This happens only for Gmail. If it is a more complex issue, then it's IMHO not worth wasting time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Alex, homepage http://www.bennee.com/~alex/

[FrostyX]

Can you replicate that with emacs -q because it works for me.

Yep, I was able to reproduce the issue. Please check out this video.

emacs-edit-server-bug.mp4

The reproducer is

1. Run emacs -q
2. Install emacs-server package and run M-x edit-server-start
3. Create a new frame with M-x make-frame
4. Go to Gmail and click Edit with Emacs

As you can see in the video, a new frame opens (which is expected), and also one of the existing frames changes.

[stsquad]

Hmm I still haven't been able to re-create on my emacs here (GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2020-12-31) but in the -q setup I did find some weirdness with delete-window getting called even though edit-server-new-frame was 't.

The only thing I can think of is somehow edit-server-show-edit-buffer gets confused and fails to select the new frame properly hence triggering the pop-to-buffer in your old frame. You could turn on debugging for the edit-server but I suspect it needs more instrumentation first.