Closed Bug 1332914 Opened 3 years ago Closed 3 years ago

[GTK] multiple text boxes can be highlighted at the same time

Categories

(Core :: Widget: Gtk, defect, P3)

52 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox51 --- unaffected
firefox52 --- fixed
firefox53 --- unaffected

People

(Reporter: ht990332, Unassigned)

References

Details

(Keywords: polish, regression, Whiteboard: tpi:+)

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170122140600

Steps to reproduce:

In firefox 52, linux/gtk3, multiple text boxes can be highlighted at the same time.
Luckily, this is not an issue on firefox 53 but since firefox 52 is going to beta soon, I felt I need to report this.
Notice the attached screenshot.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Keywords: polish
Priority: -- → P3
Whiteboard: tpi:+
What is the gtk version and theme?
GTK+ 3.22.7
Default Adwaita theme.
Thanks.  Firefox 52.0b1 and b4 reproduce also with GTK 3.20.6.  Seems to
change on hover and click.  The way that hover effects change with time
suggests this may be due to animations.

entry has "transition: all 200ms cubic-bezier(0.25, 0.46, 0.45, 0.94);"

With GTK 3.18.9, which also has this transition, I'm not seeing any blue focus
border.

Firefox 51.0b14 shows the focus ring and only as expected, with GTK 3.18 or
3.20.

This was triggered by
https://hg.mozilla.org/integration/autoland/rev/5d6136e0a045

Perhaps active and hover flags were introduced with GtkEntry like
bug 1328899, but that is having only an indirect effect, perhaps through
triggering style resolution more often.  There is something else involved.

https://hg.mozilla.org/integration/autoland/rev/99c765086bf4 seems to resolve
the symptoms.  That may be a candidate for uplift, but I'd like to understand
why that helps before doing that.
Blocks: 1282753
Status: UNCONFIRMED → NEW
Depends on: 1319957
Ever confirmed: true
Keywords: regression
If gtk_css_node_get_timestamp() doesn't find a frame clock, then it returns a
special timestamp of 0
https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssnode.c?h=3.22.8#n695
which avoids animations:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssanimatedstyle.c?h=3.22.8#n435

The frameclock lookup is performed on the root CSS node in the node hierarchy:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssnode.c?h=3.22.8#n684

In Gecko, the root CSS node currently comes from a widget and so
gtk_widget_get_frame_clock() is used to find the frame clock (if animations
are enabled in the setttings):
https://git.gnome.org/browse/gtk+/tree/gtk/gtkcsswidgetnode.c?h=3.22.8#n266
Unrealized widgets do not have a frame clock:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=3.22.8#n5786

Realizing any widget will realize its parents, and so realization of all
widgets in the hierarchy must be removed to prevent the root widget/node from
having a frame clock, which is what 99c765086bf4 does.  Taking only part of
that patch will not avoid this bug.

I'll request uplift of 99c765086bf4 to beta 52 in bug 1319957.
Hussam, the fix for this should be in Firefox 52b7, which will be made available tomorrow. Can you please verify that it's fixed? Thanks!
Flags: needinfo?(me)
It is fixed in in Firefox 52b7. Thank you.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(me)
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Sorry, it won't let me close as fixed.
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → INVALID
Resolution: INVALID → FIXED
You need to log in before you can comment on or make changes to this bug.