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.

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

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.

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).

> about:newtab (which is the only other page I know that shows an empty location bar). Doesn't happen with about:blank.

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

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).

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.

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

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.

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.

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

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.

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.

I am able to repro on Mac and Win 7

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

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.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) 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.

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.

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 :) )!