stsquad
"edit" button disappears/missing in gmail compose/reply window
I'm using today's gmail in Chrome 30 (beta).
In the gmail compose window's box for the message body, the "edit" button appears initially, but after the first time I do an edit and C-c C-c back to the browser, the button disappears.
In the gmail reply window's box for the message body, the "edit" button never appears at all.
The Alt-Enter keystroke still works in both situations.
I can re-create the problem although it looks like the button is still there just hidden behind the send button. Currently the textarea.js just naively places the img element next to the textarea in question. Perhaps with some css styling we can ensure it always floats over the textarea where-ever it may be?
@frobtech could you see if the change I've made helps your setup. It's a bit hacky but if you come up with any better positioning for css/textareas.css then please submit a patch.
I'm having the same issue, I tried editing textarea.css so that all the pixel values were 10x as big as they are currently, which turns the edit button into a GIANT edit button, e.g. it's almost as big as the GitHub text box I'm typing in now.
But I can't see it at all in the GMail interface.
I'm beginning to think the only way we can ensure the edit button is always visible it to include it inside the div or textarea block. However if we do that we will need to ensure we strip out the inline img link when we return text to the user.
However that approach is also problematic as the webapp may well zap the contents of the div/textarea during it's start-up (my experiment on Gmail confirms this).
I had a look at what It's All Text does on Firefox. It seems Firefox gets different HTML (a body tag rather than editable div) and It's All Text doesn't pick this up (or in fact any of the editable divs in my test suite). However it is interesting it's approach to positioning. It uses absolute positioning for the edit button elements, I assume based on the calulated absolute position of the bounding box of the text area it's attached to. Perhaps that is the solution to this problem on Edit with Emacs?
This might be a stupid suggestion, I'm totally unfamiliar with how Chrome manages its DOM for the purposes of writing plugins like this, but it seems the inherent issue is that emacs_chrome is trying to inject its own elements into a page without knowing much about what else is running there, so those elements can easily get hidden.
Maybe a different approach like detecting what textarea boxes are the largest in the current view, and having a button to edit those in the toolbar or via a bookmarklet would work better.
Also just having an official API for this kind of thing in Chrome would be less prone to breakage, is there an upstream bug for having something less ad-hoc for textbox editing?
I'm still seeing what I initially described in the GMail Compose box. chrome://extensions says Edit with Emacs 1.12