GMail stopped working: because it doesn't use a textarea?

Question

GMail stopped working: because it doesn't use a textarea?

attila-lendvai opened this issue 5 years ago · comments

Chromium on Debian: Version 76.0.3809.100 (Developer Build) built on Debian 10.0, running on Debian 10.1 (64-bit)

running the latest from the git repo, both in the browser and in Emacs 26.1.

commit af46de40e2991b046f04856c18a6483badce38aa (HEAD -> master, origin/master, origin/HEAD)
Author: Alex Bennée <alex.bennee@linaro.org>
Date:   Sat Mar 16 16:44:27 2019 +0000

    xmlcomms.js: actually honour the edit_server_host setting

it has stopped working in the gmail compose window, somewhere around when i updated debian (and with that i guess chromium, too). the behavior is strange: as if emacs received the contents of past invocations... and/or then the content is further html-escaped with each invocation...? but it's never showing the gmail compose contents, and sometimes it's just empty.

after investigating i noticed that gmail is not using textarea's, but then the context menu contains the edit-with-emacs button when i click there, so i guess there's already some magic in the code to deal with gmail specifically?

another strange thing that Alt+Enter (my shortcut if it's not the default) doesn't work in gmail's compose window, but it works in github textboxes.

Alex Bennée · Answer 1 · Wed Sep 18 2019 21:17:20 GMT+0800 (China Standard Time)

There isn't any special magic apart from looking for editable DIV tags instead of textareas. I'm just testing with Google Chrome and it seems to be working fine here. Do you have plain text mode enabled for your compose window?

…

On Wed, 18 Sep 2019 at 13:29, Attila Lendvai ***@***.***> wrote: Chromium on Debian: Version 76.0.3809.100 (Developer Build) built on Debian 10.0, running on Debian 10.1 (64-bit) running the latest from the git repo, both in the browser and in Emacs 26.1. commit af46de4 (HEAD -> master, origin/master, origin/HEAD) Author: Alex Bennée ***@***.***> Date: Sat Mar 16 16:44:27 2019 +0000 xmlcomms.js: actually honour the edit_server_host setting it has stopped working in the gmail compose window, somewhere around when i updated debian (and with that i guess chromium, too). the behavior is strange: as if emacs received the contents of past invocations... and/or then the content is further html-escaped with each invocation...? but it's never showing the gmail compose contents, and sometimes it's just empty. after investigating i noticed that gmail is not using textarea's, but then the context menu contains the edit-with-emacs button when i click there, so i guess there's already some magic in the code to deal with gmail specifically? another strange thing that Alt+Enter (my shortcut if it's not the default) doesn't work in gmail's compose window, but it works in github textboxes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

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

Alex Bennée · Answer 2 · Wed Sep 18 2019 21:18:26 GMT+0800 (China Standard Time)

FWIW my Google Chrome is 77.0.3865.75 (Official Build) (64-bit)

Attila Lendvai · Answer 3 · Wed Sep 18 2019 21:58:21 GMT+0800 (China Standard Time)

i have tried in both plain text and rich text modes.

errr... wait!

i have reloaded the gmail tab just now (by entering "gmail.com" into the location bar), and now ALT+Enter started to work properly. but when i issue the context menu command, then i get this into the emacs buffer:

<pre>&lt;pre&gt;&amp;lt;pre&amp;gt;&amp;amp;lt;pre&amp;amp;gt;asdfasdfasdf&amp;amp;lt;/pre&amp;amp;gt;&amp;lt;/pre&amp;gt;&lt;/pre&gt;</pre>

Alex Bennée · Answer 4 · Thu Sep 19 2019 01:07:20 GMT+0800 (China Standard Time)

That certainly looks like a non-text only mode bunch of html.

Attila Lendvai · Answer 5 · Thu Sep 19 2019 04:10:24 GMT+0800 (China Standard Time)

i also have edit-server-htmlize installed from git. i tried without, and it just got worse (ALT+Enter also contained html tags, not only when selecting from the menu).

this is how i load stuff in emacs:

(add-to-list 'load-path (expand-file-name (concat dwim-emacs-workspace "/emacs_chrome/servers")))
(require 'edit-server)
(edit-server-start)

;; to deal with the stupid new gmail compose code that uses html internally even in plain text mode
(add-to-list 'load-path (expand-file-name (concat dwim-emacs-workspace "/edit-server-htmlize")))
(autoload 'edit-server-maybe-dehtmlize-buffer "edit-server-htmlize" "edit-server-htmlize" t)
(autoload 'edit-server-maybe-htmlize-buffer   "edit-server-htmlize" "edit-server-htmlize" t)
(add-hook 'edit-server-start-hook 'edit-server-maybe-dehtmlize-buffer)
(add-hook 'edit-server-done-hook  'edit-server-maybe-htmlize-buffer)

;; KLUDGE ideally the above installed autoloads should be enough, but
;; we cannot install the local load path early enough for
;; customizations, so we cannot use customization for setting
;; EDIT-SERVER-HTMLIZE-URL-REGEXP.
(require 'edit-server-htmlize)
(setq edit-server-htmlize-url-regexp
      "^\\(mail\\.google\\.com/mail/\\|groups\\.google\\.com/forum/\\)")

Weiwu Zhang · Answer 6 · Thu Jun 11 2020 16:21:23 GMT+0800 (China Standard Time)

I can prove that the plugin can't find the textarea to focus in in Gmail even when Gmail has the "Simple Text" mode, with the following screen recording on Firefox (not Chrome but I think it shows the same problem)

Captura del escritorio de 11-06-20 18:18:32.webm.gz

Parham Doustdar · Answer 7 · Fri Jun 19 2020 01:54:12 GMT+0800 (China Standard Time)

I have also set GMail to just text instead of the rich editor, but pressing alt+enter doesn't work.

Alex Bennée · Answer 8 · Thu Dec 24 2020 05:35:55 GMT+0800 (China Standard Time)

The latest push to master fixed a problem with gmail switching to having "spellcheck=false" attributes in the editable div. If you could try the current master and confirm if it solves your problem?