Closed Bug 664287 Opened 13 years ago Closed 13 years ago

Disable site-identity button during discoverability demo?

Categories

(Firefox for Android Graveyard :: General, defect)

Firefox 6
ARM
Android
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 7

People

(Reporter: aaronmt, Assigned: wesj)

References

Details

(Whiteboard: [inbound])

Attachments

(1 file)

Mozilla/5.0 (Android; Linux armv7l; rv:6.0a2) Gecko/20110614 Firefox/6.0a2 Fennec/6.0a2

Mozilla/5.0 (Android; Linux armv7l; rv:7.0a1) Gecko/20110614 Firefox/7.0a1 Fennec/7.0a1

During the first run sidebar discoverability demo on Aurora (Firefox 6) and Nightly (Firefox 7), most of the chrome UI controls (i.e, New Tab, Preferences, Awesomebar, Reload, Bookmarks) are disabled until the demo is over. Should this include the site-identity button which is still accessible?
Attached patch PatchSplinter Review
I hate that we have to disable anything here. This special cases the identity button stuff. We don't use a command handler there, it looks like because we want access to the event in order to ensure we only toggle the identity menu in certain cases? I'm guessing that's just copied from desktop and we could simplify it?

The menu button offers another way to get to this, but showing the menu is already disabled during the discovery animation.
Assignee: nobody → wjohnston
Status: NEW → ASSIGNED
Attachment #539342 - Flags: review?
Attachment #539342 - Flags: review? → review?(mark.finkle)
What if.... we just put an overlay (like context-block) over the entire window. If the user taps the overlay, we kill the animation and remove the overlay? Otherwise we remove the overlay when the demo finishes.

I don't like putting "disable" code throughout the app for this one-time demo
Why are we disabling anything anyway? I forgot the reason.
Shield sounds like a good idea. I will look into it.

If we allow using the UI during the discoverability demo, you can get into strange states (Gray areas where the sidebars should be for instance).
Comment on attachment 539342 [details] [diff] [review]
Patch

I don't like this, but better to be consistent with this "disable" approach.
Attachment #539342 - Flags: review?(mark.finkle) → review+
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/927e4e8b3926
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
VERIFIED FIXED on:

Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:7.0a2) Gecko/20110710 Firefox/7.0a2 Fennec/7.0a2 

Device: HTC Desire Z (Android 2.2)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: