#4187 closed defect (fixed)
Focus of url entry stays when closing a tab
Reported by: | erikos | Owned by: | humitos |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | Browse | Version: | 0.97.x |
Severity: | Major | Keywords: | r+, olpc-test-passed |
Cc: | Distribution/OS: | Unspecified | |
Bug Status: | Assigned |
Description
Build: os11
Steps to reproduce:
- go into ebook mode
- open Browse
- open a new tab using the add-tab button
- close the new tab
- the url entry of the old tab is focused (you will know because the OSK is up)
Attachments (1)
Change History (9)
comment:1 Changed 11 years ago by humitos
comment:2 Changed 11 years ago by erikos
- Bug Status changed from Unconfirmed to Assigned
- Keywords triage removed
- Milestone changed from Unspecified by Release Team to 0.98
- Owner changed from manuq to humitos
- Priority changed from Unspecified by Maintainer to Normal
- Severity changed from Unspecified to Major
- Status changed from new to assigned
- Version changed from Unspecified to 0.97.x
Like discussed on irc, focus the canvas on tab close (see ff734de4e8829c9873fb84f0a9cc0166860cdd96 in sugar).
comment:3 Changed 11 years ago by humitos
- Keywords r? added
I'm attaching a patch that every time a tab is closed the focus is grabbed by WebKit.WebView of the tab that will be shown.
With this patch you won't be placed on the URL entry after closing a tab and you will be taken to the input field inside the WebView if you were on it at the moment of switching to another tab.
The only test that I couldn't fix is this one:
- Open Browse
- Go to Google
- Focus goes to the search input inside the WebKit.WebView
- Tap on the URL entry
- Add a new tab with add-tab button
- Focus goes to the URL entry
- Close the new tab
- Focus goes to the search input inside the WebKit.WebView
I would like that in this case the focus were in the WebKit.WebView but not in the search input because I've already quit from that input when I tap on the URL entry (step 4)
NOTE: this patch doesn't fix the issue related with the startup page (that case is out of the question) #4200
Changed 11 years ago by humitos
comment:4 follow-up: ↓ 5 Changed 11 years ago by manuq
Working great, only fails when the prevvious tab has a PDF, the entry is left focused and there is an error in the log:
Traceback (most recent call last): File "/home/olpc/Activities/Browse.activity/webtoolbar.py", line 351, in __switch_page_cb self._connect_to_browser(tabbed_view.props.current_browser) File "/home/olpc/Activities/Browse.activity/webtoolbar.py", line 360, in _connect_to_browser address = self._browser.props.uri or self._browser.loading_uri AttributeError: 'DummyBrowser' object has no attribute 'loading_uri'
comment:5 in reply to: ↑ 4 Changed 11 years ago by humitos
comment:6 Changed 11 years ago by manuq
- Keywords r+ olpc-test-pending added; r? removed
- Resolution set to fixed
- Status changed from assigned to closed
Great, pushed as 0f656938 .
comment:7 Changed 11 years ago by greenfeld
- Keywords olpc-test-passed added; olpc-test-pending removed
We restore focus to the previous tab as appropriate and do not leave the on-screen keyboard displaying attempting to type text in a field which no longer exists in Browse-148/OLPC 13.1.0 os20.
Well this bug report is quite tricky. I'm not sure that the problem is related to the focus.
The Home Page (OLPC Library) has another bug (related with Javascript) that puts the focus in the Google input but it is not a "clean" focus. I say "clean" because the cursor blinking is not shown and "Backspace" does not work (#4200).
So, let's check with another page instead of the Home Page:
Test 1:
Test 2:
Test 3:
Are these behaviours right?
It's like the focus is always in the WebKit.WebView widget (on tab switching) and OSK only if this widget has the focus inside an input field.