In gedit's Replace window, a single Tab does not move focus from Search to Replace field

Bug #491555 reported by David Siegel on 2009-12-02
44
This bug affects 9 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Low
Unassigned
gedit
Expired
Low
gedit (Ubuntu)
Low
Unassigned

Bug Description

When the user opens the Replace dialog (Search > Replace...), the default input focus lies in the Search field. The user types the search string, and presses tab to enter the replacement string, but the input focus moves from the Search field to the choice disclosure control instead of to the Replace field. Pressing Tab in the Search field should move input focus to the Replace field. The search field can recall history by pressing Up/Down arrows, and offers autocomplete, so changing the Tab focus chain does not prevent the user from recalling a previous search string.

Red: Choice disclosure control that currently receives input focus when Tab is pressed in Search field.
Green: Replace field, which should be the next control to receive focus when Tab is pressed in the Search field.

summary: - In Replace window, a single Tab does not move focus from Search to
- Replace field
+ In gedit's Replace window, a single Tab does not move focus from Search
+ to Replace field
Omer Akram (om26er) on 2010-01-23
Changed in hundredpapercuts:
importance: Undecided → Low
status: New → Triaged
Vish (vish) on 2010-06-11
Changed in hundredpapercuts:
milestone: none → maverick-round-2-mail+office
Changed in gedit (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in gedit:
status: Unknown → New
Changed in hundredpapercuts:
assignee: nobody → Bilal Akhtar (bilalakhtar)
Changed in gedit (Ubuntu):
assignee: nobody → Bilal Akhtar (bilalakhtar)
status: Triaged → In Progress
Changed in hundredpapercuts:
status: Triaged → In Progress
Ken VanDine (ken-vandine) wrote :

I tried the patch, it didn't seem to fix the problem. Initially I was seeing an error in the console:

sys:1: GtkWarning: GtkEntry - did not receive focus-out-event. If you
connect a handler to this signal, it must return
FALSE so the entry gets the event as well

So I added a return FALSE to gedit_history_entry_set_tab_index_callback, which suppressed the error but didn't actually make tab focus the replace entry. I still get the selector focused on tab.

Bilal Akhtar (bilalakhtar) wrote :

Cannot fix it, anyone else?

Changed in hundredpapercuts:
assignee: Bilal Akhtar (bilalakhtar) → nobody
status: In Progress → Triaged
Changed in gedit (Ubuntu):
status: In Progress → Triaged
assignee: Bilal Akhtar (bilalakhtar) → nobody
Andrew (and471) wrote :

There is a patch upstream.

Changed in gedit:
importance: Unknown → Low
Vish (vish) on 2010-11-23
Changed in hundredpapercuts:
milestone: maverick-round-2-office → nt5-office
Vish (vish) on 2010-11-26
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Changed in gedit (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Nik (krnekhelesh)
Changed in gedit (Ubuntu):
assignee: Nik (krnekhelesh) → nobody
status: In Progress → New
Bilal Akhtar (bilalakhtar) wrote :

If you can't work on a bug, then please set it back to Confirmed or Triaged and not New.

Changed in gedit (Ubuntu):
status: New → Triaged

On 11/26/10 at 12:20pm, Papercuts Bug Mailer wrote:
> You have been assigned a bug task for a public bug by Vish (vish):
>
> When the user opens the Replace dialog (Search > Replace...), the
> default input focus lies in the Search field. The user types the search
> string, and presses tab to enter the replacement string, but the input
> focus moves from the Search field to the choice disclosure control
> instead of to the Replace field. Pressing Tab in the Search field should
> move input focus to the Replace field. The search field can recall
> history by pressing Up/Down arrows, and offers autocomplete, so changing
> the Tab focus chain does not prevent the user from recalling a previous
> search string.
>
> ** Affects: gedit
> Importance: Low
> Status: New
>
> ** Affects: hundredpapercuts
> Importance: Low
> Assignee: Papercuts Ninja (papercuts-ninja)
> Status: Triaged
>
> ** Affects: gedit (Ubuntu)
> Importance: Low
> Status: Triaged
I want to get start with this bug. I have one problem. I did:

$ bzr branch lp:ubuntu/gedit gedit
$ cd gedit
$ bzr bd -- -S -us -uc

I got errors:
http://pastie.org/1367760

Any suggestions?

Robert Sajdok (ris) wrote :

Problem is solved. I installed a few other packages.

Robert Sajdok (ris) on 2010-12-15
Changed in gedit (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Robert Sajdok (ris)
Robert Sajdok (ris) wrote :

I tried to fix this bug but I encountered the problem. Function: set_focus_chain is not available in stable version of Gtk+. This function corresponds for "tab order" I think the good decision will be waiting to stable version of Gtk+ after that fix this bug.

Changed in gedit (Ubuntu):
status: In Progress → New
assignee: Robert Sajdok (ris) → nobody
Robert Sajdok (ris) wrote :

Please change staus bug to: "Triaged"

Vish (vish) wrote :

Robert Sajdok , thanks for taking a look at this bug..!
No worries though that it dint work.. :) Feel free to take a shot at the other papercuts : <https://bugs.launchpad.net/hundredpapercuts/+bugs?field.status%3Alist=TRIAGED> .

Changed in gedit (Ubuntu):
status: New → Triaged
Robert Sajdok (ris) wrote :

@Vish
Yes. I am very keen in this project. I am looking for another bug now :)

Vish (vish) on 2011-01-13
Changed in hundredpapercuts:
assignee: Papercuts Ninja (papercuts-ninja) → nobody
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Christopher Overton (muonata) wrote :

I see this bug listed in "One Hundred Paper Cuts nt5-office "Evolution , gedit & LibO" associated with natty development. When I populated gedit and ran 'replace' dialog pressing tab with focus attached at search field hadn't reproduced this bug, or in otherwords, tabbing focus from 'search' to 'replace' seems to work as desired. Should this bug still be open for this development branch?

Chris Wilson (notgary) wrote :

Christopher Overton, I was indeed able to reproduce this bug in Gedit version 2.30.4 that ships with Natty. I observed that when I press Tab when in the search field, focus is shifted first to the button that reveals the search field's dropdown menu, and a second tab is required to move into the replace field.

Chris Wilson (notgary) on 2011-12-07
Changed in hundredpapercuts:
milestone: nt5-office → precise-3-productivity
Chris Wilson (notgary) on 2012-06-12
Changed in hundredpapercuts:
milestone: precise-3-productivity → quantal-2-productivity
Chris Wilson (notgary) on 2012-11-29
Changed in hundredpapercuts:
milestone: quantal-2-productivity → gedit
Ben (pumrum) wrote :

I confirmed this is still an issue with:

Ubuntu 12.04.2 64bit Alternate, Fresh Install
gEdit 3.4.1

Leonardo Donelli (learts92) wrote :

Still an issue on Ubuntu 13.04, gEdit 3.6.2
There's a patch upstream by a gEdit developer, almost 3 years old. It works, but another developer said he doesn't like it (code-style-wise). Maybe we could implement it as Debian patch while we wait for an upstream solution?

Chris Wilson (notgary) on 2013-05-23
Changed in hundredpapercuts:
milestone: gedit → papercuts-s-1-gedit
Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
Changed in gedit:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.