Closed
Bug 495058
Opened 16 years ago
Closed 15 years ago
Location bar emptyText not shown when deteaching blank tab or about:privatebrowsing into a new window
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
Tracking | Status | |
---|---|---|
status1.9.1 | --- | .2-fixed |
People
(Reporter: whimboo, Assigned: dao)
References
Details
(Keywords: verified1.9.1)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
beltzner
:
approval1.9.1.2+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre ID:20090527031214
When you have about:privatebrowsing open and deteach this tab to a new window the focus is not set to the location bar. Instead it is empty and even doesn't display any emptyText.
Steps:
1. Switch into Private Browsing mode
2. Open another tab
3. Deteach tab with about:privatebrowsing into a new window
After step 3 the focus is not set to the location bar.
Comment 1•16 years ago
|
||
Why would we want to set the focus to the location bar if the about:privatebrowsing tab is detached?
Reporter | ||
Comment 2•15 years ago
|
||
Ok, this is a more general issue. Same happens with a blank tab. If we don't set the focus to the location bar then we should display at least the emptyText. It's not set by this action. Morphing summary accordingly.
Component: Private Browsing → Tabbed Browser
QA Contact: private.browsing → tabbed.browser
Summary: No focus in locationbar when deteaching tab with about:privatebrowsing into a new window → Location bar emptyText not shown when deteaching blank tab or private browsing page into a new window
Comment 3•15 years ago
|
||
Henrik, could you please check this with a build before bug 462041 landed to see if it's a regression in that bug? I'm guessing so, just want to make sure.
Comment 4•15 years ago
|
||
Nevermind, using the DOM Inspector I verified that the emptytext attribute is indeed being set correctly. So, I'm not sure what's happening there.
One this that caught my attention is that if a new tab is opened on the detached window, and then the first tab is selected again, the empty text shows this time.
Comment 5•15 years ago
|
||
Henrik, it would be good if you can check to see if it's a problem caused by bug 471512...
Summary: Location bar emptyText not shown when deteaching blank tab or private browsing page into a new window → Location bar emptyText not shown when deteaching blank tab or about:privatebrowsing into a new window
Reporter | ||
Comment 6•15 years ago
|
||
Before the patch on 471512 we haven't used an emptyText. We have always set "about:privatebrowsing" as the location bar value. What do we wanna have now?
Switching into PB mode and blurring the location bar shows us the "Search bookmarks and history" emptyText. Is that what we wanna have? No about:privatebrowsing anymore?
Comment 7•15 years ago
|
||
(In reply to comment #6)
> Before the patch on 471512 we haven't used an emptyText. We have always set
> "about:privatebrowsing" as the location bar value. What do we wanna have now?
I think the goal is that the behavior of about:privatebrowsing matches that of about:blank (i.e., never show about:privatebrowsing in the location bar). When I talked about testing this with a build before bug 471512, I meant with an about:blank tab of course.
> Switching into PB mode and blurring the location bar shows us the "Search
> bookmarks and history" emptyText. Is that what we wanna have? No
> about:privatebrowsing anymore?
Yes.
Reporter | ||
Comment 8•15 years ago
|
||
So this issue should depend on the patch of bug 471512.
Comment 9•15 years ago
|
||
(In reply to comment #8)
> So this issue should depend on the patch of bug 471512.
Yes, probably. Are you confirming that this is a regression from that patch?
Reporter | ||
Comment 10•15 years ago
|
||
Not yet. Just an assumption. It is a low prio for me right now. Will try to get the range sometimes in the next days. If another one has interest in doing this, feel free.
Keywords: regressionwindow-wanted
Reporter | ||
Comment 11•15 years ago
|
||
Not sure if we can really call it a regression but the reported behavior started with the 090303 builds on trunk. Since this date we don't use the "about:privatebrowsing" when switching into PB mode. Alex, what does UX think about?
Blocks: 471512
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → dao
No longer blocks: 471512
Component: Tabbed Browser → General
Keywords: regression,
uiwanted
QA Contact: tabbed.browser → general
Assignee | ||
Comment 12•15 years ago
|
||
The emptyText setter updates the displayed value if needed.
Attachment #381397 -
Flags: review?(gavin.sharp)
Updated•15 years ago
|
Attachment #381397 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•15 years ago
|
Attachment #381397 -
Flags: approval1.9.1?
Comment 13•15 years ago
|
||
Either displaying the epmtyText or giving the location bar the focus is fine.
Assignee | ||
Comment 14•15 years ago
|
||
Flags: in-testsuite+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Comment 15•15 years ago
|
||
Dão, what needs to be checked in here?
Comment 16•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/ad24e23c05a6#l1.39
Is it safe to assume that the above setTimeout won't cause random oranges under heavy loads in which delayedStartup might take more than 100ms to run?
Assignee | ||
Comment 17•15 years ago
|
||
(In reply to comment #15)
> Dão, what needs to be checked in here?
The patch, once mozilla-central is open.
I tag my own bugs checkin-needed in order to not lose track of them, even though I'll land them myself in most cases.
(In reply to comment #16)
> Is it safe to assume that the above setTimeout won't cause random oranges under
> heavy loads in which delayedStartup might take more than 100ms to run?
If delayedStartup takes more than 100ms, that will also defer the test's setTimeout callback.
Assignee | ||
Comment 18•15 years ago
|
||
this is what really needs to land
Attachment #381397 -
Attachment is obsolete: true
Attachment #382468 -
Flags: approval1.9.1?
Attachment #381397 -
Flags: approval1.9.1?
Assignee | ||
Comment 19•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6a1
Assignee | ||
Updated•15 years ago
|
Attachment #382468 -
Flags: approval1.9.1?
Assignee | ||
Updated•15 years ago
|
Attachment #382468 -
Flags: approval1.9.1.1?
Reporter | ||
Comment 20•15 years ago
|
||
Verified fixed on OS X and Windows with a build like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090703 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090703050112
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•15 years ago
|
Attachment #382468 -
Flags: approval1.9.1.1? → approval1.9.1.2?
Comment 21•15 years ago
|
||
Comment on attachment 382468 [details] [diff] [review]
patch + test update
a1912=beltzner
Attachment #382468 -
Flags: approval1.9.1.2? → approval1.9.1.2+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 22•15 years ago
|
||
status1.9.1:
--- → .2-fixed
Keywords: checkin-needed
Assignee | ||
Comment 23•15 years ago
|
||
Reporter | ||
Comment 24•15 years ago
|
||
Verified fixed on 1.9.1 with builds on OS X and Windows like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2pre) Gecko/20090727 Shiretoko/3.5.2pre ID:20090727031954
Keywords: verified1.9.1
Comment 25•9 years ago
|
||
Comment 26•8 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•