476672 - Selecting current tab doesn't close tab area

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Ben Combee (:bcombee)]

When you drag the tab area open and there's only one tab, you can't close the tab area by tapping on your tab -- you have to drag the page back.  The same applies with multiple tabs; selecting the active tab does nothing.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

This is working ok for me. Sounds like an error is occurring somewhere and breaking the normal behavior.

Look in the error console (start fennec with the -jsconsole flag)

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch

The onselect of the richlistbox was not firing if you clicked the already selected tab. Even if you did, we protect against setting the tab to the selected tab, so it would hide the tabs area anyway. Also, BrowserUI.show(UIMODE_NONE) was not hiding the tabs area either.

This patch gives the job of hiding the tabs area to BrowserUI.hideTabs() and we call this method on mouseup in the tabs area.

Comment 3

[Ben Combee (:bcombee)]

Comment on attachment 360363 [details] [diff] [review]
patch

What will happen if you mouse down in the tabs, but drag off them and release?  Does the  richlistbox do the equivalent of a grab so the up will be tracked?

I'm also thinking of the eventual interface here where you can scroll through the tabs to preview pages.  Can we set it to keep firing select events as the user moves his finger across different tabs?

Comment 4

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

Won't this patch prevent us from unfreezing the urlbar (via this._showToolbar(false))?

Panning the widgetstack based on the toolbar width seems rather hacky... I think I'd prefer keeping the panTo(0, 0) workaround for now.

Comment 5

[Stuart Parmenter]

(In reply to comment #3)
> (From update of attachment 360363 [details] [diff] [review])
> What will happen if you mouse down in the tabs, but drag off them and release? 
> Does the  richlistbox do the equivalent of a grab so the up will be tracked?

You'd get a mouse down but not a mouse up which won't result in a click event being fired.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch 2 - less changes

this patch puts the BrowserUI.show(UIMODE_NONE) back, so other code that calls BrowserUI.show with other modes still works. It also keeps the ws.panTo(0, 0, true) behavior we use in tab switching.

(I will kill BrowserUI.show in it's own bug)

Comment 7

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

(In reply to comment #4)
> Won't this patch prevent us from unfreezing the urlbar (via
> this._showToolbar(false))?

This still seems like a potential problem with that patch, if someone calls closeTab without also calling hideTabs. I suppose it isn't a problem for our UI since the onmouseup handle will always be called?

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #7)
> (In reply to comment #4)
> > Won't this patch prevent us from unfreezing the urlbar (via
> > this._showToolbar(false))?
> 
> This still seems like a potential problem with that patch, if someone calls
> closeTab without also calling hideTabs. I suppose it isn't a problem for our UI
> since the onmouseup handle will always be called?

Right, hideTabs is the API for making the tabstrip disappear. This will be used later, more explicitly, when we add features that don't hide the tabstrip immediately after selecting a tab.

Comment 9

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

Comment on attachment 360420 [details] [diff] [review]
patch 2 - less changes

OK, sorry for the delay.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

http://hg.mozilla.org/mobile-browser/rev/067419de05ba

Comment 11

[Anna (Waverley)]

VERIFIED FIXED on:

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110523 Firefox/6.0a1 Fennec/6.0a1 

Device: HTC Desire Z (Android 2.2)