Closed
Bug 933989
Opened 12 years ago
Closed 12 years ago
Defect - New tab button in tab bar always sets focus to the url bar, triggering soft keyboard
Categories
(Firefox for Metro Graveyard :: App Bar, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 28
People
(Reporter: jimm, Assigned: rsilveira)
References
Details
(Whiteboard: [block28] feature=defect c=tbd u=tbd p=1)
Attachments
(2 files)
|
4.03 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
|
2.02 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
rather annoying ux bug, the url bar shouldn't get focus so that the sk comes up obscuring about:start in the new tab.
str:
1) swipe in the tabbar
2) tap the plus button
result: a new tab is opened, the url bar gains focus, and the skb is displayed.
Updated•12 years ago
|
Blocks: metrov1backlog
Summary: New tab button in tab bar always sets focus to the url bar, triggering soft keyboard → Defect - New tab button in tab bar always sets focus to the url bar, triggering soft keyboard
Whiteboard: [triage] → [triage] feature=defect c=tbd u=tbd p=0
Updated•12 years ago
|
Whiteboard: [triage] feature=defect c=tbd u=tbd p=0 → [release28] feature=defect c=tbd u=tbd p=0
| Reporter | ||
Comment 1•12 years ago
|
||
I'm still able to reproduce on 11-3 nightly. STR
1) open about start
2) tab the urlbar to bring up the keyboard
3) tap the start page white space to dismiss the soft keyboard
4) swipe in tab tray
5) click new tab button
result: tab open, focus is on the urlbar, skb comes up
Updated•12 years ago
|
Assignee: nobody → rsilveira
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Whiteboard: [release28] feature=defect c=tbd u=tbd p=0 → [block28] feature=defect c=tbd u=tbd p=1
| Assignee | ||
Comment 2•12 years ago
|
||
Added a new command for keyboard shortcut, it's handy to start typing after pressing ctrl+t. Will not focus on url bar after click/tapping the new tab button.
Attachment #8341391 -
Flags: review?(mbrubeck)
Updated•12 years ago
|
Attachment #8341391 -
Flags: review?(mbrubeck) → review+
Updated•12 years ago
|
Attachment #8341451 -
Flags: review?(mbrubeck) → review+
| Assignee | ||
Comment 4•12 years ago
|
||
Comment 5•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Comment 6•12 years ago
|
||
Went through the following defect for iteration #20 without any issues. Used the following build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-12-16-03-02-02-mozilla-central/
- Went through the original test case from comment #0 without any issues
- Went through the test case from comment #1 without any issues
- Ensured that when the OSK is visible, using CTRL + T would focus on the Navigation App Bar in the new start tab without sliding in the OSK
- Ensured that when the OSK isn't visible, using CTRL + T would focus on the Navigation App Bar in the new start tab without sliding in the OSK
- Ensured that opening a new tab via the overlay button after dismissing the OSK doesn't trigger the OSK in the new start tab
- Opened several new tabs while the OSK was visible while browsing and ensured that the OSK didn't trigger in the new start tabs being created
- Ensured that once the OSK was dismissed from a website, creating a new tab wouldn't trigger the OSK in the new start tabs being created
- Ensured that the OSK isn't triggered in the new tab when the user taps on either Top Sites, Bookmarks or Recent History while the OSK is visible/not visible
- Went through all of the above test cases using filled view without any issues
You need to log in
before you can comment on or make changes to this bug.
Description
•