Closed
Bug 452080
Opened 16 years ago
Closed 16 years ago
Display navigation screen when the URL bar is activated
Categories
(Firefox for Android Graveyard :: General, defect, P2)
Firefox for Android Graveyard
General
Tracking
(Not tracked)
VERIFIED
FIXED
fennec1.0a1
People
(Reporter: madhava, Assigned: enndeakin)
Details
(Whiteboard: UI polish)
Attachments
(3 files, 1 obsolete file)
1.48 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
17.30 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
17.22 KB,
patch
|
Details | Diff | Splinter Review |
Fennec behaviour should be as described here: https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI#Navigation_to_a_new_page At the moment (M7), the URL bar activates (gets a cursor) when tapped, and awesomebar results appear when the user begins to type, but pre-typing awesomebar listings are not shown, and no search buttons are displayed.
Updated•16 years ago
|
Assignee: nobody → mark.finkle
Flags: wanted-fennec1.0+
Priority: -- → P2
Updated•16 years ago
|
Assignee: mark.finkle → enndeakin
Comment 1•16 years ago
|
||
neil, can you take a look at this please?
Assignee | ||
Comment 2•16 years ago
|
||
Currently, the existing url is displayed when the url field is focused. Is the idea here to 1. clear the url field and display the 'default' history results whenever it is focused 2. show history results that match the current url, or 3. leave the field at its current value, show 'default' history and then change the results when editing the field? Search buttons would be displayed if the search components were built (that's bug 444735). The UI for that is already implemented, although running it in a current build, the hourglass icon appears in the wrong place which should be an easy fix.
Comment 3•16 years ago
|
||
I think #3 is the idea.
Assignee | ||
Comment 4•16 years ago
|
||
- show only the first four search engines - display default autocomplete on click and when there are no results There is some flicker as the results switch between matches and the default.
Assignee | ||
Comment 5•16 years ago
|
||
This patch changes the height calculation so that if the popup has a height attribute explicitly set, the height is not adjusted.
Assignee | ||
Comment 6•16 years ago
|
||
The other toolkit patch makes this flicker less when typing when there are no matches. The search service change in bug 444735 is needed for the search buttons to appear.
Attachment #337718 -
Attachment is obsolete: true
Attachment #337884 -
Flags: review?(mark.finkle)
Assignee | ||
Comment 7•16 years ago
|
||
Comment on attachment 337883 [details] [diff] [review] change to autocomplete.xml to eliminate flickering Not sure how to test this.
Attachment #337883 -
Flags: review?(gavin.sharp)
Comment 8•16 years ago
|
||
Comment on attachment 337884 [details] [diff] [review] updated autocomplete and search patch >diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js > >- openDefaultHistory : function () { >- if (!this._edit.value) { >- this._autocompleteNavbuttons.hidden = true; Looks like you remove any need for _autocompleteNavbuttons with this patch. You could remove the other occurrences where we init the value.
Attachment #337884 -
Flags: review?(mark.finkle) → review+
Updated•16 years ago
|
Attachment #337883 -
Flags: review?(gavin.sharp) → review+
Comment 9•16 years ago
|
||
Comment on attachment 337884 [details] [diff] [review] updated autocomplete and search patch >diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js >+ container.appendChild(button, container.firstChild); appendChild only takes one argument :) >- this._edit.focus(); >+ // nasty way to focus the edit field >+ document.commandDispatcher.advanceFocusIntoSubtree(document.getElementById("urlbar-container")); Why is this needed?
Assignee | ||
Comment 10•16 years ago
|
||
> >+ // nasty way to focus the edit field
> >+ document.commandDispatcher.advanceFocusIntoSubtree(document.getElementById("urlbar-container"));
>
> Why is this needed?
Actually, I realize we can just use:
this._edit.inputField.focus()
I will make these changes.
Assignee | ||
Comment 11•16 years ago
|
||
Comment 12•16 years ago
|
||
is this ready to land?
Assignee | ||
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•