GNOME Bugzilla – Bug 143467
context menu on textfields should be like context menu on GtkEntry
Last modified: 2015-09-28 13:32:19 UTC
The context menu on text fields and textareas should be like the context menu on a GtkEntry. Namely: - unavailable functions (Copy, Paste, Cut with no clipboard content resp. no selection) is insensitive but still visible (see also bug 139040) - there's the submenu with the input methods to allow switching the input method. Right now if you want to use another input method in a web form field, you have to go to the url bar, right click and choose another input method, then go back to the form input field. VERY unintuitive.
First issue fixed. Is adding an input methods submenu possible at all ? Otherwise this doesnt seem fixable :/ Something we could easily add is the Select All item.
Looking at gtkentry.c: popup_targets_received() where GtkEntry builds its menu: It uses gtk_im_multicontext_append_menuitems() to build the list of input methods. This function is public; however there appears to be no way to get the GtkIMMulticontext of the embed? And the special chars sub-menu is built using a non-public function, _gtk_text_util_append_special_char_menuitems(), so i don't think we could have that part :/
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Has there been any change in the GTK+ situation? Else I'd like to open a bug there.
It's depending on gtk+ bug 500196, but it's also depending on mozilla exposing the GtkIMContext of the widget (sort of like https://bugzilla.mozilla.org/show_bug.cgi?id=164793 but that doesn't fit exactly). It's proabably to late to try this for xr 1.9 :-(
Sorry, I meant gtk bug 500065.
Gecko as the backend is deprecated. Thus I suppose this bug is obsolete now, isn't it? Considering that WebKit's context menu for text widgets is pretty much the same as GtkEntry's with two extra items.
Technically gecko is still the supported back-end for the stable release, but realistically I don't see any action happening on this bug before we switch to webkit.
BTW, the webkit context menu is from webkit, not from epiphany. We still need a way to provide our own context menu, and that context menu still will need these entries. So this bug is not obsolete.
(In reply to comment #9) > BTW, the webkit context menu is from webkit, not from epiphany. We still need a > way to provide our own context menu, and that context menu still will need > these entries. So this bug is not obsolete. I don't see a contradiction here. You can use the 'populate-popup' signal in which case you do not have to create all menus (which you incidentally can't do in the first place with the current WebKit API).
I insist that all menus be dynamic with gtkuimanager; populate-popups makes that impossible. > (which you incidentally can't do > in the first place with the current WebKit API). Which is a problem in webkit, not obsoleting this bug.
Point taken, if you need fully customizable entry popups, that's fine. In that case the bug should probably be renamed accordingly, though.
(In reply to comment #11) > I insist that all menus be dynamic with gtkuimanager; populate-popups makes > that impossible. > > > (which you incidentally can't do > > in the first place with the current WebKit API). > > Which is a problem in webkit, not obsoleting this bug. > Hey, So, I had a first stab at wrapping Command and EditCommand to GtkAction. Results are fairly successful, but limited to editing actions right now. Might be able to extend this idea to navigation actions, ideally reusing the same infrastructure. Heard there's an IRC meeting on Monday. Will be good to catch up and discuss the strategy.
It has been a while, this bug should probably be reviewed for relevance.
(In reply to Christian Persch from comment #0) > - unavailable functions (Copy, Paste, Cut with no clipboard content resp. no > selection) is insensitive but still visible (see also bug 139040) Got that nowadays. > - there's the submenu with the input methods to allow switching the input > method. Got that too.