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

[attila-lendvai]

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 <[email protected]>
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.

[stsquad]

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/

[stsquad]

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

[attila-lendvai]

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>

[stsquad]

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

[attila-lendvai]

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/\\)")

[SmartLayer]

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

[parhamdoustdar]

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

[stsquad]

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?