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)

VERIFIED FIXED in Firefox 28

Status

()

Firefox
Private Browsing
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Aleksej, Assigned: Ehsan)

Tracking

({regression, reproducible})

16 Branch
Firefox 28
regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox25 affected, firefox26 affected, firefox27 affected, firefox28 affected, firefox-esr17 ?, firefox-esr24 ?)

Details

(Whiteboard: [testday-20131108] IGNORE FIRST 2 SENTENCES IN COMMENT #0 [bugday-20131111])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Reporter)

Comment 1

5 years ago
So it was at least in Firefox 25.0 betas and 26.0 betas.
(Reporter)

Comment 2

5 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

5 years ago
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).
Blocks: 763468
Keywords: regression
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Comment 4

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

Doesn't happen with about:blank.
(Reporter)

Comment 5

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

Comment 6

5 years ago
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).
(Reporter)

Comment 7

5 years ago
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.
(Reporter)

Updated

5 years ago
Keywords: reproducible
Summary: Soon after a private browsing tab or window opens, contents of urlbar is selected → lost by further typing → Soon after a private browsing tab or window opens, contents of urlbar is selected → lost by further typing (make Fx slower to reproduce easier)
(Reporter)

Updated

5 years ago
Summary: Soon after a private browsing tab or window opens, contents of urlbar is selected → lost by further typing (make Fx slower to reproduce easier) → Soon after a private browsing tab or window (about:privatebrowsing) opens, contents of urlbar is selected → lost by further typing (especially when Fx is busy/slow)
Version: unspecified → Trunk
Aleksej, I assume given your regression range that this happens for you also in Firefox 17esr and Firefox 24esr?
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected
status-firefox-esr17: --- → ?
status-firefox-esr24: --- → ?
Version: Trunk → 16 Branch
(Reporter)

Comment 9

5 years ago
Created attachment 829408 [details]
screencast of the bug
(Assignee)

Comment 10

5 years ago
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.
(Assignee)

Comment 11

5 years ago
Created attachment 829414 [details] [diff] [review]
Patch (v1)
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #829414 - Flags: review?(gavin.sharp)
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.
Severity: major → normal
Summary: Soon after a private browsing tab or window (about:privatebrowsing) opens, contents of urlbar is selected → lost by further typing (especially when Fx is busy/slow) → 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)
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
OS: Linux → All
Hardware: x86_64 → All
(Assignee)

Comment 17

5 years ago
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.
Attachment #829414 - Flags: review?(gavin.sharp) → review+
(Reporter)

Comment 19

5 years ago
(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.
(Reporter)

Updated

5 years ago
Whiteboard: [testday-20131108] → [testday-20131108] IGNORE FIRST 2 SENTENCES IN COMMENT #0
(Assignee)

Comment 20

5 years ago
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.
https://hg.mozilla.org/mozilla-central/rev/874c670c2cb0
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
(Reporter)

Comment 23

5 years ago
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 :) )!
Status: RESOLVED → VERIFIED
Whiteboard: [testday-20131108] IGNORE FIRST 2 SENTENCES IN COMMENT #0 → [testday-20131108] IGNORE FIRST 2 SENTENCES IN COMMENT #0 [bugday-20131111]
You need to log in before you can comment on or make changes to this bug.