Closed Bug 771551 Opened 8 years ago Closed 7 years ago

Add CSS Media Query media feature for device hardware buttons

Categories

(Core :: CSS Parsing and Computation, enhancement)

All
Gonk (Firefox OS)
enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: don, Assigned: mwu)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, Whiteboard: [DocArea=CSS])

Attachments

(1 file, 4 obsolete files)

Adding CSS Media Query media features for the presence of device hardware buttons such as "Home" "Back" and "Option" would allow B2G/Gaia to display appropriate softkeys on screen when running on devices that lack hard keys.

E.G. When running on the Galaxy Nexus, Gaia could use media features to detect the absence of a hardware "Home" button to display an additional softkey.
Status: UNCONFIRMED → NEW
Ever confirmed: true
FWIW, I filed bug 763846 for this previously.
"Style System" is really only the right component for a tiny piece of this -- the stub that goes in layout/style/nsMediaFeatures.cpp that hooks into the actual code elsewhere.
Attached patch Add -moz-no-nav-buttons feature (obsolete) — Splinter Review
I don't know what a good name would be for this, but I used -moz-no-nav-buttons. Suggestions welcome.
Assignee: nobody → mwu
You could be explicit and call it -moz-physical-home-button so that we can do -moz-physical-back-button etc. if needed.
(Also the CSS selector should probably not be a negative, e.g. -moz-foo, not -moz-no-foo)
It seems more difficult to get -moz-physical-home-button working, so I just renamed it to -moz-no-physical-button.

I was trying a media query like:

@media not (-moz-physical-home-button)

but I couldn't get it working.

@media (-moz-no-physical-home-button)

works though.

dbaron, what do you think of this approach?
Attachment #745441 - Attachment is obsolete: true
Attachment #746611 - Flags: feedback?(dbaron)
When this is done we can work on https://bugzilla.mozilla.org/show_bug.cgi?id=796369
Blocks: 796369
(In reply to arkanciscan from comment #7)
> When this is done we can work on
> https://bugzilla.mozilla.org/show_bug.cgi?id=796369

We should start work on that as soon as possible. Figuring out/adjusting how to turn the home button on/off based on media queries seems minor compared actually implementing the home button.
(In reply to Michael Wu [:mwu] from comment #6)
> Created attachment 746611 [details] [diff] [review]
> Rename to -moz-no-physical-home-button
> 
> It seems more difficult to get -moz-physical-home-button working, so I just
> renamed it to -moz-no-physical-button.
> 
> I was trying a media query like:
> 
> @media not (-moz-physical-home-button)
> 
> but I couldn't get it working.
> 
> @media (-moz-no-physical-home-button)
> 
> works though.
> 
> dbaron, what do you think of this approach?

I'd really much rather avoid negatives in the query names, as vlad said.

I think the syntax is a little annoying, in that you can't use 'not' without a media type, so you'd need to write the query as:

@media not all and (-moz-physical-home-button)
Attachment #746611 - Flags: feedback?(dbaron) → feedback-
Attached patch Add -moz-physical-home-button (obsolete) — Splinter Review
This seems to work. The media query syntax is clumsy, but it works.
Attachment #746611 - Attachment is obsolete: true
Attachment #750607 - Flags: review?(vladimir)
Attachment #750607 - Flags: review?(dbaron)
Comment on attachment 750607 [details] [diff] [review]
Add -moz-physical-home-button

Looks fine to me, though dbaron's review counts for more here :)  I'm not a huge fan of having the system property be No* again, but I understand that it's so that we don't need to modify the property list for devices that do have a hardware button.  But maybe we should still keep the prop be PhysicalHomeButton, and just negate the prop?
Attachment #750607 - Flags: review?(vladimir) → review+
This one removes no- from everywhere else.
Attachment #750607 - Attachment is obsolete: true
Attachment #750607 - Flags: review?(dbaron)
Attachment #750634 - Flags: review?(dbaron)
Comment on attachment 750634 [details] [diff] [review]
Add -moz-physical-home-button, v2

roc, do you mind reviewing this?
Attachment #750634 - Flags: review?(dbaron) → review?(roc)
Comment on attachment 750634 [details] [diff] [review]
Add -moz-physical-home-button, v2

Review of attachment 750634 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/style/nsCSSRuleProcessor.cpp
@@ +1195,5 @@
>    }
>  
> +  rv = LookAndFeel::GetInt(LookAndFeel::eIntID_PhysicalHomeButton,
> +                           &metricResult);
> +  if (NS_FAILED(rv) || metricResult) {

Can you explain why you want to have the PhysicalHomeButton system metric property existing when the look and feel doesn't recognise the ID?  None of the other properties there seem to operate like that.
(In reply to Cameron McCormack (:heycam) from comment #14)
> Can you explain why you want to have the PhysicalHomeButton system metric
> property existing when the look and feel doesn't recognise the ID?  None of
> the other properties there seem to operate like that.

We're trying to turn -moz-physical-home-button on by default, and then turn it off on the small set of devices that don't have a physical home button - mostly Nexus devices. I originally had it named NoPhysicalHomeButton, which would have operated a bit more intuitively, but it seems like people aren't fans of names starting with "no". Getting rid of it makes things a bit weird compared to other properties.
Presumably it should be "on by default" on mobile platforms, but off by default on desktop platforms?
(And given that we, I think, have fewer look-and-feel implementations for mobile platforms that desktop ones, it seems like it might be better to do the quoted bit above the normal way, and then just make sure that all the nsILookAndFeel implementations on mobile platforms recognize the ID appropriately?)
(In reply to David Baron [:dbaron] (in W3C meetings through June 11) (don't cc:, use needinfo? instead) from comment #16)
> Presumably it should be "on by default" on mobile platforms, but off by
> default on desktop platforms?

Well, there's also B2G desktop builds. It might be ok to show the soft homebutton there though.
(In reply to Michael Wu [:mwu] from comment #18)
> (In reply to David Baron [:dbaron] (in W3C meetings through June 11) (don't
> cc:, use needinfo? instead) from comment #16)
> > Presumably it should be "on by default" on mobile platforms, but off by
> > default on desktop platforms?
> 
> Well, there's also B2G desktop builds. It might be ok to show the soft
> homebutton there though.

We have a [Home] key usable there, but on the other hand the simulator folks added a soft button to their chrome to help with discoverability.
I agree you should avoid having a negative in the name, but I also think the metric should be set in the same way as all the others in nsCSSRuleProcessor.cpp.  Can you do that, and then make all LAFs recognise the metric ID and set it appropriately?  Assuming that either you are OK with B2G desktop builds showing the button, or that it is possible to make B2G desktop builds' LAF indicate that there is no home button.
Desktop builds should not block anything here. Worse case we can use a pref to specify on desktop if we need the button or not.
The system metric checking is now the same as everything else.
Attachment #750634 - Attachment is obsolete: true
Attachment #750634 - Flags: review?(cam)
Attachment #758924 - Flags: review?(cam)
Comment on attachment 758924 [details] [diff] [review]
Add -moz-physical-home-button, v3

Michael tells me he's happy for the media query to evaluate to false on other platforms, so r=me even without any changes to the other LAFs.
Attachment #758924 - Flags: review?(cam) → review+
It would be good to get a correct Android implementation, though.  Could you at least file a followup bug for that and make sure Android widget code maintainers know about it?
Blocks: 880103
(In reply to David Baron [:dbaron] (in W3C meetings through June 11) (don't cc:, use needinfo? instead) from comment #24)
> It would be good to get a correct Android implementation, though.  Could you
> at least file a followup bug for that and make sure Android widget code
> maintainers know about it?

Bug filed, but I'm not sure if there's value in reporting anything other than no physical home button. Android always takes the home button event AFAIK, so there's nothing for the page do. On the other hand, if we always report that there is no physical home button, a home button can be made available that makes gaia potentially usable on Fennec.
https://hg.mozilla.org/mozilla-central/rev/3b44958f4b63
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Is it possible to uplift this to v1-train?
(In reply to Dietrich Ayala (:dietrich) from comment #28)
> Is it possible to uplift this to v1-train?

Probably, though it's not a trivial cherry-pick AFAICT.
(In reply to Michael Wu [:mwu] from comment #26)
> (In reply to David Baron [:dbaron] (in W3C meetings through June 11) (don't
> cc:, use needinfo? instead) from comment #24)
> > It would be good to get a correct Android implementation, though.  Could you
> > at least file a followup bug for that and make sure Android widget code
> > maintainers know about it?
> 
> Bug filed, but I'm not sure if there's value in reporting anything other
> than no physical home button. Android always takes the home button event
> AFAIK, so there's nothing for the page do. On the other hand, if we always
> report that there is no physical home button, a home button can be made
> available that makes gaia potentially usable on Fennec.

Gaia isn't the point.  The point is that you're adding a new feature to the Web platform, and that feature should be implemented correctly.  Since Android devices often have a home button, the media query should reflect that.
(In reply to David Baron [:dbaron] (in W3C meetings through June 11) (don't cc:, use needinfo? instead) from comment #30)
> Gaia isn't the point.  The point is that you're adding a new feature to the
> Web platform, and that feature should be implemented correctly.  Since
> Android devices often have a home button, the media query should reflect
> that.

Well, they often have a home button, but that home button isn't available in any meaningful way AFAIK. There's no direct way of capturing a home button event, so telling a page that it doesn't need to show a home button doesn't seem useful on an Android device.
Whiteboard: [DocArea=CSS]
You need to log in before you can comment on or make changes to this bug.