After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 143467 - context menu on textfields should be like context menu on GtkEntry
context menu on textfields should be like context menu on GtkEntry
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Interface
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on: 332968 500065
Blocks: 755524
 
 
Reported: 2004-06-01 00:39 UTC by Christian Persch
Modified: 2015-09-28 13:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2004-06-01 00:39:24 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.
Comment 1 Marco Pesenti Gritti 2004-06-07 23:45:09 UTC
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.
Comment 2 Christian Persch 2004-06-08 00:06:06 UTC
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 :/
Comment 3 Christian Persch 2004-10-13 10:50:54 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 4 Reinout van Schouwen 2007-12-18 21:27:36 UTC
Has there been any change in the GTK+ situation? Else I'd like to open a bug there.
Comment 5 Christian Persch 2007-12-18 21:46:23 UTC
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 :-(
Comment 6 Christian Persch 2007-12-18 21:47:12 UTC
Sorry, I meant gtk bug 500065.
Comment 7 Christian Dywan 2008-10-07 11:05:02 UTC
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.
Comment 8 Reinout van Schouwen 2008-10-07 11:36:16 UTC
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.
Comment 9 Christian Persch 2008-10-07 11:38:09 UTC
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.
Comment 10 Christian Dywan 2008-10-07 12:39:51 UTC
(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).
Comment 11 Christian Persch 2008-10-07 13:03:10 UTC
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.

Comment 12 Christian Dywan 2008-10-07 13:20:08 UTC
Point taken, if you need fully customizable entry popups, that's fine. In that case the bug should probably be renamed accordingly, though.
Comment 13 alp 2008-10-19 03:43:14 UTC
(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.

Comment 14 Chris Leonard 2012-05-04 23:28:14 UTC
It has been a while, this bug should probably be reviewed for relevance.
Comment 15 Michael Catanzaro 2015-09-28 13:32:19 UTC
(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.