1193391 - about:home / newtab search fields are not cleared

Status: RESOLVED INVALID

(Firefox :: Search, defect, P2)

Description

[Petruta Horea [:phorea], Desktop QA]

Reproduced with 42.0a1 (2015-08-10), all platforms.

For about:newtab page:
Enter some text in the search field and restart the browser (don't perform the search). 
AR: The entered text is still displayed after restart.

For about:home page:
Enter some text in the search field and perform the search. Press "Go back one page" button or the Backspace key.
AR: The entered text remains the the search field

ER: In both cases, the text should be cleared.

Comment 1

[:shell escalante]

ask UX if this is desired - likely behavior assuming crash, but not intentional?

Comment 2

[Stephen Horlander [:shorlander]]

We aren't 100% consistent here but maintaining text in fields between restarts is a feature of Session Restore. Whether you have that on as default or if you hit the button on about:home. If you don't use Session Restore this should not happen.

Comment 3

[:shell escalante]

need to talk to about:home and new tab folks - want to find out if there's a way to specify if a field shouldn't be restored in HTML.

Comment 4

[Drew Willcoxon :adw]

Attachment: SessionStore.ignoreIDs() proof of concept

This fixes the restart cases on both about:home and newtab when I call SessionStore.ignoreIDs() on them from the browser console.  If this approach is OK I'll write a test and another patch for the about:home/newtab parts.

(In reply to Petruta Rasa [QA] [:petruta] from comment #0)
> For about:home page:
> Enter some text in the search field and perform the search. Press "Go back
> one page" button or the Backspace key.
> AR: The entered text remains the the search field

I'm not so sure that's a problem.  If it's a privacy concern, it doesn't really make sense because the page you visit before about:home while navigating backward is the search results page itself.  If it's a UX concern, it's actually a good thing that your search query is still in the text field when you navigate backward from the search results page IMO.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8660249 [details] [diff] [review]
SessionStore.ignoreIDs() proof of concept

Review of attachment 8660249 [details] [diff] [review]:
-----------------------------------------------------------------

A few things:

1) I'm not convinced this is really a problem. Do we have a word from UX on whether this is something we actually want to fix? If I'm about to start a search and accidentally hit Cmd+Q or the browser crashes then I think I'd be happy to see my search term isn't gone when Firefox comes back. Same thing if I accidentally close the tab and then restore it.

2) A simple blacklist in FormDataListener.handleEvent() might be sufficient to exclude the two pages, although that's not great either.

3) If it's only that one tiny search field then could we just clear those in onbeforeunload()? Although that wouldn't cover cases like restoring a closed tab mentioned above.

Comment 6

[Petruta Horea [:phorea], Desktop QA]

(In reply to Drew Willcoxon :adw from comment #4)
> (In reply to Petruta Rasa [QA] [:petruta] from comment #0)
> > For about:home page:
> > Enter some text in the search field and perform the search. Press "Go back
> > one page" button or the Backspace key.
> > AR: The entered text remains the the search field
> 
> I'm not so sure that's a problem.  If it's a privacy concern, it doesn't
> really make sense because the page you visit before about:home while
> navigating backward is the search results page itself.  If it's a UX
> concern, it's actually a good thing that your search query is still in the
> text field when you navigate backward from the search results page IMO.

Drew, I filed it from the UX perspective because for Firefox 41 and older versions, the search term is not kept.

Comment 7

[Stephen Horlander [:shorlander]]

(In reply to Tim Taubert [:ttaubert] from comment #5)
> Comment on attachment 8660249 [details] [diff] [review]
> SessionStore.ignoreIDs() proof of concept
> 
> Review of attachment 8660249 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> A few things:
> 
> 1) I'm not convinced this is really a problem. Do we have a word from UX on
> whether this is something we actually want to fix? If I'm about to start a
> search and accidentally hit Cmd+Q or the browser crashes then I think I'd be
> happy to see my search term isn't gone when Firefox comes back. Same thing
> if I accidentally close the tab and then restore it.

Retaining the text between restarts if you don't initiate a search, or in the case of a crash, is what I would expect to happen with Session Restore on. It's true that this behavior does not exist in release, not sure how or why this changed.

The case where you go back to about:home from a SERP is a little odd because we don't always do the same thing with back navigation and form inputs AFAICT. In this case I think it would be good in case you are going back to make a change to your search term. The problem with it here is that when we go back from a SERP to about:home we are placing the cursor at the beginning of the field instead of the end, making it harder to modify your search terms.

Comment 8

[Drew Willcoxon :adw]

Sounds like this is not a bug then.

(In reply to Stephen Horlander [:shorlander] from comment #7)
> The problem with it here is that when we go back from a SERP to
> about:home we are placing the cursor at the beginning of the
> field instead of the end, making it harder to modify your
> search terms.

That's almost certainly due to Gecko and not something in the front end.  I poked around a little in the selection code but couldn't find where it happens.  We should file a new bug if we really want to fix that.