Closed Bug 628732 Opened 9 years ago Closed 9 years ago

Hitting Android Back in Awesome list opens right panel

Categories

(Firefox for Android Graveyard :: General, defect, P1, major)

ARM
Android

Tracking

(fennec2.0+)

VERIFIED FIXED
Tracking Status
fennec 2.0+ ---

People

(Reporter: tarend, Assigned: vingtetun)

References

Details

(Keywords: ux-userfeedback)

Attachments

(2 files, 1 obsolete file)

Attached video opening side panel
I saw this on Nexus One and Droid II with 20110125 nightly:

(1) open a few pages in tabs (at least three)
(2) on a page (with no side panels open), tap into awesome bar (list and VKB appears)
(3) use Android back button twice (to close VKB and then to go back to original page)

Result: right panel opens
Expected: page shows with no side panel open.


See attached vid. Potentially related to Bug 613485
tracking-fennec: --- → ?
See Also: → 613485
Assignee: nobody → 21
tracking-fennec: ? → 2.0+
Attached patch Patch (obsolete) — Splinter Review
Settings the height of the tabs container should re-order childs (the tabs), it looks like the reflow that should happened because of the moz-column rules arrive later expected.

The patch just wrap the calculation inside an executeSoon call.
Since tabs.resize();  (that wrap the call) is called during startup we need to be sure there is no bad startup effect hidden into that trick.
Attachment #507194 - Flags: review?(mark.finkle)
Comment on attachment 507194 [details] [diff] [review]
Patch

Does this work in tabs.xml?

setTimeout(function() { self._updateWidth(); }, 0)

r+, but use the setTimeout if it works - it's easier to understand, I think
Attachment #507194 - Flags: review?(mark.finkle) → review+
(In reply to comment #2)
> Comment on attachment 507194 [details] [diff] [review]
> Patch
> 
> Does this work in tabs.xml?
> 
> setTimeout(function() { self._updateWidth(); }, 0)
> 
> r+, but use the setTimeout if it works - it's easier to understand, I think

setTimeout(..., 0); does not work, which is why I have used the executeSoon code :/
Also I would like to play a bit with the patch before, it seems to fix an other bug (bug 615334) but the bad news is the time gap before the repositioning of the scrollbars is a few ms longer and this is very noticeable on device (having the filing to see ghost sidebars every time I switch orientation)

I would like to see if I can find a way to reduce this delay.
Attached patch PatchSplinter Review
Ok, I have tried a bunch of different options here (even hacking the nsViewManager to pause update of the screen while resizing the tabs container...) and this is the best I have.

It fixes this bug and bug 615334 and stays quick on device!
Attachment #507416 - Flags: review?(mark.finkle)
Attachment #507416 - Flags: review?(mark.finkle) → review+
Comment on attachment 507194 [details] [diff] [review]
Patch

I assume this patch is not needed
Attachment #507194 - Attachment is obsolete: true
http://hg.mozilla.org/mobile-browser/rev/a8e4a7e239b2
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
VERIFIED FIXED:

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre Fennec /4.0b5pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.