Closed
Bug 1492736
Opened 5 years ago
Closed 5 years ago
[remote-dbg-next] Prevent locking device when connected to remote debugging
Categories
(DevTools :: about:debugging, enhancement, P3)
DevTools
about:debugging
Tracking
(firefox65 fixed)
RESOLVED
FIXED
Firefox 65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: jdescottes, Assigned: m_kato)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
Feature requested for web compat support. When a Device is being remote debugged, it should not lock. This feature is currently available in Chrome's remote debug solution.
Updated•5 years ago
|
Blocks: devtools-webcompat-team
Comment 1•5 years ago
|
||
I believe Makoto is looking into this.
Assignee | ||
Comment 2•5 years ago
|
||
Past years, we have implemented WeakLock API for B2G (and also Android backend). We may be able to use that API for this.
Assignee | ||
Comment 3•5 years ago
|
||
Ah, bug 1369194 removed WebIDL...
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → m_kato
Assignee | ||
Comment 4•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4301a1bdf20280fc2fd514b25eb0d91c0f07745a
Assignee | ||
Comment 5•5 years ago
|
||
DevTools wants to use wake lock to keep screen. But since MozWakeLock is removed by bug 1369194, there is no way to unlock wake lock from script. So this issue adds nsIWakeLock to unlock wake lock.
Assignee | ||
Comment 6•5 years ago
|
||
Use wake lock to keep screen when tab is attached from debugger. Depends on D7158
Assignee | ||
Comment 7•5 years ago
|
||
Julian, I have a question for this. Chrome/Android seems to keep wake lock when devtool in desktop selects same tab in remote device. Example, when remote device has A and B tab, and foreground in remote device is A tab, devtool only keeps wake lock when devtool selects foreground's A tab. If devtool selects B tab (B isn't foreground in remote device), wake lock is unlocked. Does Firefox's devtools use same behaviour? Or, when device is connected (via wifi or USB) to devtool, should wake lock be kept even if selected tab in devtool isn't foreground in remote device?
Flags: needinfo?(jdescottes)
Reporter | ||
Updated•5 years ago
|
Flags: needinfo?(jdescottes)
Comment 8•5 years ago
|
||
> Or, when device is connected (via wifi or USB) to devtool, should wake lock be kept even if selected tab in devtool isn't foreground in remote device?
Chrome's behavior seems more like a side effect. Is there value for users that I am missing that tab-centric wake-lock adds?
Assignee | ||
Comment 9•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #8) > > Or, when device is connected (via wifi or USB) to devtool, should wake lock be kept even if selected tab in devtool isn't foreground in remote device? > > Chrome's behavior seems more like a side effect. Is there value for users > that I am missing that tab-centric wake-lock adds? I don't know. I think that Chrome approach is that they connect to device automatically (remote device tab of Chrome shows "connected" state when adb connection is found), so they acquire wake lock when selecting tab. Our devtool connects to device manually, so I think that it is better to acquire wake lock when connected to device.
Comment 10•5 years ago
|
||
Pushed by m_kato@ga2.so-net.ne.jp: https://hg.mozilla.org/integration/mozilla-inbound/rev/77ccb4525731 Part 1. Add nsIWakeLock to manage wake lock from devtools. r=baku https://hg.mozilla.org/integration/mozilla-inbound/rev/e358e36fc048 Part 2. Acquire wake lock when device actor is attached. r=ochameau
Comment 11•5 years ago
|
||
Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6868407681bb Fix eslint failure, missing comma. r=me
Comment 12•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/77ccb4525731 https://hg.mozilla.org/mozilla-central/rev/e358e36fc048 https://hg.mozilla.org/mozilla-central/rev/6868407681bb
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
You need to log in
before you can comment on or make changes to this bug.
Description
•