GNOME Bugzilla – Bug 642403
Selecting text in URL bar doesn't highlight if page is encrypted
Last modified: 2011-06-07 14:34:51 UTC
When a page is encrypted, the text in the URL bar doesn't highlight when it is selected. It still selects in the normal way, it just doesn't highlight as it should. Epiphany 2.91.6, GTK+ 3.0.0.
Still present with Epiphany 2.91.91, GTK+ 3.0.2
Created attachment 183534 [details] [review] Fix for bug 642403: Selecting text in URL bar doesn't highlight if page is encrypted
Review of attachment 183534 [details] [review]: Looks simple, I'd just ask if this wasn't supposed to be a GTK+ bug? Anyway, looks simple, I'm just confused by the color lookup I commented. Thanks for the patch storm btw :-) ::: lib/widgets/ephy-location-entry.c @@ +190,3 @@ + { + gtk_style_context_lookup_color (style, "selected_bg_color", &priv->secure_selected_bg_color); + } I'm a bit confused with this one... so if there's nothing returned by gtk_style_context_get_style in the previous block, then it asks again? @@ +352,1 @@ + g_type_class_add_private (object_class, sizeof (EphyLocationEntryPrivate)); Is this an intentional re-indent? It's ok if it's so, I think. But just double-checking, sometimes editors play tricks.
*** Bug 545662 has been marked as a duplicate of this bug. ***
When there is agreement on a patch, could you ask the release team for a freeze break?
Alexandre, Diego?
FYI I noted the same issue in rhythmbox search entry; so maybe, if possible, the fix should be in gtk+ to benefit all.
*** Bug 647906 has been marked as a duplicate of this bug. ***
*** Bug 648007 has been marked as a duplicate of this bug. ***
Diego, regarding a question if this is a bug in Gtk+. From http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-override-color "Note that for complex widgets this may bring in undesired results (such as uniform background color everywhere), in these cases it is better to fully style such widgets through a GtkCssProvider with the GTK_STYLE_PROVIDER_PRIORITY_APPLICATION priority." So, it is at least documented to work like this, so it must be designed in such a way. In my opinion, it would be nice to make this themeable as well using a CSS class, but it is a tricky deal: if it's not something generic that all themes would have, then it shouldn't be in a theme. But, any pre-selected colour scheme will not work with all themes, so it seems we've got a no-win situation.
(In reply to comment #3) > Review of attachment 183534 [details] [review]: > > Looks simple, I'd just ask if this wasn't supposed to be a GTK+ bug? > Anyway, looks simple, I'm just confused by the color lookup I commented. > > Thanks for the patch storm btw :-) > > ::: lib/widgets/ephy-location-entry.c > @@ +190,3 @@ > + { > + gtk_style_context_lookup_color (style, "selected_bg_color", > &priv->secure_selected_bg_color); > + } > > I'm a bit confused with this one... so if there's nothing returned by > gtk_style_context_get_style in the previous block, then it asks again? He's asking for the not secure bg/fg color when the secure one is not found, not for the same one again. So that part looks sane to me.
Let's ship this in 3.0.1, I'm not committing in master in case we want to come up with a better solution.
We don't paint stuff in yellow in master anymore, closing.