936417 - Soon after a private browsing tab or window (about:privatebrowsing) opens, contents of urlbar is selected and lost by further typing (especially when Fx is busy/slow)

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect)

Description

[[:Aleksej]]

This happens with my Firefox Beta profile, even in Safe mode, but not with a new profile.
I started using PB windows a month or two ago and have always had this problem.

1. Open a Private Browsing window, or a tab in such a window.
2. Very quickly, put (type) text into the address bar.

Actual results:
In a second or less, the text is selected.  So it is deleted if I am still typing.

Comment 1

[[:Aleksej]]

So it was at least in Firefox 25.0 betas and 26.0 betas.

Comment 2

[[:Aleksej]]

Reproduced with a new profile with 2013-11-07-03-02-00-mozilla-central-firefox-28.0a1.en-US.linux-x86_64.

I guess anything that adds slowness may help, like autofill possibilities, tabs open.

Comment 3

[[:Aleksej]]

WFM: 2012-06-23-03-05-32-mozilla-central-firefox-16.0a1.ru.linux-x86_64 bb4b37094b9f
Bug: 2012-06-24-03-05-37-mozilla-central-firefox-16.0a1.en-US.linux-x86_64 cb2904476d14

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bb4b37094b9f&tochange=cb2904476d14

There about:privatebrowsing was added for new private tabs: bug 763468.

It happens with browser.newtab.url set to about:privatebrowsing.
It does not happen with any other value, including about:newtab (which is the only other page I know that shows an empty location bar).

Comment 4

[[:Aleksej]]

> about:newtab (which is the only other page I know that shows an empty location bar).

Doesn't happen with about:blank.

Comment 5

[[:Aleksej]]

At comment #0 step 2, it is enough to type a single character immediately after Ctrl+t.

Comment 6

[Ioana (away)]

I managed to reproduce this issue on a Firefox 26 Aurora build from a few weeks ago on Ubuntu 12.10 64bit once, but I couldn't repeat it (on the same build, nor on beta builds).

I tried but couldn't reproduce it at all on Ubuntu 13.04 32bit and Windows 7 64bit (Firefox 26 Aurora and current beta builds).

Comment 7

[[:Aleksej]]

I can reproduce with both
2013-11-08-03-02-04-mozilla-central-firefox-28.0a1.en-US.linux-i686
2013-11-08-03-02-04-mozilla-central-firefox-28.0a1.en-US.linux-x86_64

It is much easier if Firefox is slow (e.g., something is loading), so that there is a delay before the selection (and the Awesomebar dropdown) appears.

Comment 8

[u279076]

Aleksej, I assume given your regression range that this happens for you also in Firefox 17esr and Firefox 24esr?

Comment 9

[[:Aleksej]]

Attachment: screencast of the bug

Comment 10

[(no longer active)]

This is the code which does this: <http://mxr.mozilla.org/mozilla-central/source/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml#65> which was added in bug 471512.  This is in fact not needed in the new world of per-window private browsing any more.

Comment 11

[(no longer active)]

Attachment: Patch (v1)

Comment 12

[Tracy Walker [:tracy]]

I can reproduce the text selection in URL bar of new private window simply by starting to type as soon as I click the menu item to open the new private window.

Comment 13

[u279076]

Do we have better steps to reproduce? Try as I might, I can't reproduce this at all.

Comment 14

[Tracy Walker [:tracy]]

0) not sure this is necessary, but have focus in url bar of initial window so you can compare what is lost to selection/overwrite and what was simply typed before the new window is open.
1) Click File > New Private Window
2) Without waiting for the new window to open, start typing a word (note: the first typed character(s) may end up in the initial browser url bar)

At some point the new window opens and some characters are input, selected and overwritten by continued typing.

Comment 15

[u279076]

Still doesn't reproduce for me, but that's okay. I think there's enough people on this bug to verify it's fixed when the patch lands.

Comment 16

[Tracy Walker [:tracy]]

I am able to repro on Mac and Win 7

Comment 17

[(no longer active)]

FWIW the bug is obvious from the code, I didn't try hard to reproduce it!

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 829414 [details] [diff] [review]
Patch (v1)

I don't really understand why per-window PB makes a difference here - the decision in bug 471512 seemed somewhat orthogonal to whether one new window appears or all windows are replaced. But I suppose it doesn't make much sense to have the open-PB-window case differ from the open-normal-window case, and the open-normal-window case already defaults to focusing the location bar when there content doesn't otherwise steal focus (as with about:home), so this seems redundant either way.

Comment 19

[[:Aleksej]]

(In reply to :Gavin Sharp (email [e-mail]) from comment #18)
> I don't really understand why per-window PB makes a difference here - the

Whatever you mean, there was no per-window PB in the first builds where this bug appeared.

Comment 20

[(no longer active)]

The reason why per-window PB makes a difference here is that in the global PB world, the first about:privatebrowsing tab which appeared after switching in to private browsing would not have its location bar focused without this code.

Comment 21

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/874c670c2cb0

Comment 22

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/874c670c2cb0

Comment 23

[[:Aleksej]]

VERIFIED FIXED with 2013-11-11-03-02-05-mozilla-central-firefox-28.0a1.en-US.linux-x86_64 (while loading flickr.com, compared to 2013-11-10).  Thanks, Ehsan (and those who tried to reproduce it with varying degrees of success :) )!