Closed
Bug 945996
Opened 11 years ago
Closed 10 years ago
cannot take screenshots in some devices because no home button
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(b2g-v2.1 fixed)
RESOLVED
FIXED
2.0 S4 (20june)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | fixed |
People
(Reporter: dietrich, Assigned: dietrich)
References
Details
(Whiteboard: [Flatfish])
Attachments
(1 file, 3 obsolete files)
* on software home button devices (galaxy nexus, nexus 4), you can't take a screenshot of the lock screen because there's no home button displayed then
* on some tablet devices, we'll likely the same issue
Assignee | ||
Comment 1•11 years ago
|
||
Pointer to Github pull-request
Assignee | ||
Comment 2•11 years ago
|
||
Comment on attachment 8342027 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/14329
Makes volume-down+sleep the shortcut for screenshots.
Now always works for softbutton and tablet devices, and matches Android convention.
Upon reflection, should probably be long-press of the combo, and ensure it does *not* fire the sleep/volume events. So just asking feedback about the idea as a whole.
Changing the shortcut would also address bug 940230 (flatfish screenshots).
We'd also need to let the Dev Tools team know so they can update their code.
Attachment #8342027 -
Flags: feedback?(dflanagan)
Assignee | ||
Comment 4•11 years ago
|
||
Also cannot take a screenshot of notification screen when pulled down, since covers software home button.
Comment 5•11 years ago
|
||
Comment on attachment 8342027 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/14329
The code looks fine to me, except that I wonder about the change to firing this on release instead of onpress. See my comments on github about that. Seems like that makes it harder to get the keystrokes right. But I haven't actually tried the patch out to see how it feels.
Is the screenshot feature documented anywhere? What are the implications of changing it? Does the support team need to be notified? Is this a dev-doc-needed case? Should we add the new screenshot key combination but keep the old one to ease the transition?
Do we need UX approval for a change like this?
Finally, while you're working on screenshot stuff, I just noticed a message in logcat today complaining about mozGetAsFile at b2g/chrome/content/shell.js:1141. That needs to change to use the async toBlob() function instead, if you care to tack a gecko change on to this gaia change.
Attachment #8342027 -
Flags: feedback?(dflanagan) → feedback+
Assignee | ||
Comment 6•11 years ago
|
||
UX, asking basic feedback on this change. Primarily a developer feature, and the status quo is broken in some circumstances *and* were the outlier.
Flags: needinfo?(firefoxos-ux-bugzilla)
Assignee | ||
Comment 7•11 years ago
|
||
This is also just much easier to do with your hand than home+sleep (which is awkward and takes two hands).
Comment 8•11 years ago
|
||
It seems like the question here is "Is this patch, which makes volume-down+sleep the shortcut for screenshots, acceptable?" Since it's developer focused, we're fine with this. We don't have much else we'd suggest instead.
If I've misinterpreted something, please let me know.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?
Updated•11 years ago
|
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Apologies. In making a change it somehow cleared the needinfo, but oddly the needinfo had no assignee (dunno how that works).
Either way, I'd still like to add a ping to this bug as Flatfish devices are being sent out to testers and this will be extremely helpful for testing and bug reporting.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(dietrich)
Assignee | ||
Comment 10•10 years ago
|
||
Updated patch.
Failing two tests in hardware buttons test, investigating.
Attachment #8342027 -
Attachment is obsolete: true
Flags: needinfo?(dietrich)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → dietrich
Assignee | ||
Comment 12•10 years ago
|
||
Passing the tests now.
Tim, can you do a review, especially with an eye on the test changes?
While the hardware button tests are passing now, I didn't fully understand a couple of the assertions in the related tests, so not sure "passing" means "correct" ;)
Attachment #8427890 -
Attachment is obsolete: true
Attachment #8429658 -
Flags: review?(timdream)
Comment 13•10 years ago
|
||
Comment on attachment 8429658 [details]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/19606/files
You are right, I've left some comment on Github.
Attachment #8429658 -
Flags: review?(timdream) → feedback+
Assignee | ||
Comment 14•10 years ago
|
||
Comment on attachment 8429658 [details]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/19606/files
Ok, there's still an outstanding comment, but I'm not sure there's anything that has to be done about it before landing this, so requesting final review. I'll squash commits and update the commit msg prior to landing.
"We also need to figure out should the user press Volume Down before HOLD_INTERVAL or REPEAT_DELAY?"
I think the answer is yes, but we didn't handle that before if not. Those values are only 50ms difference, which doesn't matter much here.
Also, there are failures on the Travis run, but don't have anything to do with this patch, looks like.
Attachment #8429658 -
Flags: review?(timdream)
Comment 15•10 years ago
|
||
Comment on attachment 8429658 [details]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/19606/files
For the purpose of the review, this bug is r+'d for landing after you squash the commits and ensure there are no test breakage (maybe rebase the branch too?).
Yet after the last review, I realized we can always take the screenshot with software home button or swipe up (if it's enabled), so comment 0 is not really happening (the description is "one CANNOT take a screenshot on these devices). So if we still want to change the combo of taking screenshot after finding that fact, please proceed to land this bug.
Attachment #8429658 -
Flags: review?(timdream) → review+
Assignee | ||
Comment 16•10 years ago
|
||
> For the purpose of the review, this bug is r+'d for landing after you squash
> the commits and ensure there are no test breakage (maybe rebase the branch
> too?).
Yes, definitely. I've been rebasing, running the tests locally and checking Travis as I go ;)
> Yet after the last review, I realized we can always take the screenshot with
> software home button or swipe up (if it's enabled), so comment 0 is not
> really happening (the description is "one CANNOT take a screenshot on these
> devices). So if we still want to change the combo of taking screenshot after
> finding that fact, please proceed to land this bug.
Not during FTU and some other fullscreen uses. Also, a bunch of places don't actually work well with software home button. And since no production devices support software home button, those places don't really get fixed.
Also, the current home+sleep is awkward enough. Imagine how awkward swipeup+sleep will be :)
I'll canvas dev-gaia to get some thoughts before landing.
Comment 17•10 years ago
|
||
Just want to add my 2 cents here. The software home button does not have any visual feedback right now but IMHO that is a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1018040
If that changes in future then using the slide from edge to take an screenshot -- we have to watch out not to capture the transition.
For what is worth, galexy s4 has an interesting feature which is taking a screenshot by just swiping edge of your hand on the screen. In some strange way, it sort of resembles scanning the screen with your hand. Its simple, easy to remember and also cleans your phone/tablet a little but everytime you do it :P... well that depends actually. Anyways, I thought I mention that here in case an special hand gesture like that could become available in FirefoxOS.
Cant wait for this to land, taking screenshots with app manager is not very convenient.
Comment 18•10 years ago
|
||
Dietrich, did you by chance test this with screen reader enabled? Does the screen reader toggle (volume up, down, up, down, up, down, then announcement, then up, down, up, down, up, down again) still work to turn screen reader on and off, still work?
Assignee | ||
Comment 19•10 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #18)
> Dietrich, did you by chance test this with screen reader enabled? Does the
> screen reader toggle (volume up, down, up, down, up, down, then
> announcement, then up, down, up, down, up, down again) still work to turn
> screen reader on and off, still work?
Yep, works still :)
Assignee | ||
Comment 20•10 years ago
|
||
Green Travis run: https://travis-ci.org/mozilla-b2g/gaia/builds/27703252
Assignee | ||
Comment 21•10 years ago
|
||
Green Travis run in previous comment, just cloned the branch because rebase hell.
Carrying over r+.
Attachment #8429658 -
Attachment is obsolete: true
Attachment #8441612 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 22•10 years ago
|
||
One failure in latest Travis run, but looks unrelated to this change.
https://travis-ci.org/mozilla-b2g/gaia/jobs/27805475
The test is apps/callscreen/test/unit/handled_call_test.js. Confirmed that it passes locally.
Tim, any idea if this failure could be related to this change somehow?
Flags: needinfo?(timdream)
Comment 24•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-b2g-v2.1:
--- → fixed
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S4 (20june)
You need to log in
before you can comment on or make changes to this bug.
Description
•