Closed Bug 1055436 Opened 10 years ago Closed 10 years ago

The history pane is only displayed if at least one direct URL was accessed before

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: avaida, Unassigned)

Details

Reproducible on:
 * Windows 7 64-bit, Ubuntu 14.04 LTS 32-bit, Mac OS X 10.4.0
 * Nightly 34.0a1 (2014-08-18), Aurora 33.0a2 (2014-08-18), Firefox 32 Beta 7 (Build ID: 20140814150857)

STR:
1. Launch Firefox using a *new* profile.
2. Type in a keyword in the Location Bar and press the <enter> key (e.g. 'mozilla' w/o the apostrophe).
3. Click the arrow pointing down to display the history pane.
4. Select the Location Bar again and type in a complete URL and press the <enter> key (e.g. 'mozilla.org' w/o the apostrophe).
5. Click the arrow pointing down to display the history pane.

ER:
3. The history pane is displayed, with 1 entry available for the search performed at step 2.
5. The history pane is displayed, with 2 entries available, one for the search performed at step 2 and another for the URL accessed at step 4.

AR:
3. Clicking the arrow pointing down has no effect, the history pane is not displayed at all if a URL access was not made prior to this action.
5. The history pane is displayed, but only 'mozilla.org' is displayed as an entry.

Additional notes:
 * This issue is not a regression, the same behavior can be encountered all the way back to Firefox 4.0 (Build ID: 20110318052756).
 * This issue is reproducible across platforms.
 * This bug was filed as a follow-up from the testing performed on Bug 1053357. See Comment 3 and Comment 4 for context.
this is not a bug because the empty-search behavior (the drop down arrow) only includes typed urls, that is urls the user directly typed into the locationbar. It's correct that only the second url appears cause it's the only typed in url.

So, it is working as expected by design.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Hm, from a UX point of view, wouldn't it make sense to extend the concept of "typed" (not internally, but for the purposes of the "empty search" case) to anything that is a result of the user typing in the URL bar (with frecency taken into account of course)?

In other words, for many users there isn't a logical difference between the case where they type "mozilla" and the one where they type "mozilla.org" (if they ever type "mozilla.org" at all).
(In reply to :Paolo Amadini from comment #2)
> Hm, from a UX point of view, wouldn't it make sense to extend the concept of
> "typed" (not internally, but for the purposes of the "empty search" case) to
> anything that is a result of the user typing in the URL bar (with frecency
> taken into account of course)?

that would require a lot of new code to track it, a new transition type and so on... it looks like the benefit doesn't overcome the cost. This issue is likely to be visible in a new profile, but after just a couple weeks of browsing it's unlikely the user will even notice something missing.
Also, adding more data here is unlikely to give more value to the results, it's likely doing the opposite. we only have 12 positions to fill up, typed urls sounds like having more benefit than "any result that come from the user typing anything in the urlbar".

> In other words, for many users there isn't a logical difference between the
> case where they type "mozilla" and the one where they type "mozilla.org" (if
> they ever type "mozilla.org" at all).

Well, we historically always considered typed uris to have more value cause it's clear the user wanted to go to those very specific pages, so they must be more important than a page he reached through a google link.

I think the test case it makes this issue much more visible than it is, it is really just an edge-case nobody ever noticed imo.
You need to log in before you can comment on or make changes to this bug.