Closed
Bug 1239242
Opened 9 years ago
Closed 9 years ago
[Presentation WebAPI] support start session with designated device
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla46
Tracking | Status | |
---|---|---|
firefox46 | --- | fixed |
People
(Reporter: schien, Assigned: schien)
References
Details
Attachments
(1 file, 1 obsolete file)
20.01 KB,
patch
|
schien
:
review+
|
Details | Diff | Splinter Review |
For browser UI or system-level Gaia app, they usually have following UX flow for launching presentation request: 1. browser UI displays available devices 2. user picks a device 3. user picks an action to perform Since browser UI already have the privilege to know device list via XPCOM [1] or PresentationDeviceInfo API [2], we should provide an `PresentationRequest.startWithDevice(deviceId)` for skipping the device selection prompt. [1] https://dxr.mozilla.org/mozilla-central/source/dom/presentation/interfaces/nsIPresentationDeviceManager.idl [2] https://wiki.mozilla.org/WebAPI/PresentationDeviceInfoAPI
Assignee | ||
Comment 1•9 years ago
|
||
For any code that can access PresentationDeviceInfo API should be able to use PresentationRequest.startWithDevice().
Attachment #8707394 -
Flags: review?(bugs)
Comment 2•9 years ago
|
||
Comment on attachment 8707394 [details] [diff] [review] start-with-device-api.patch >+ while(NS_SUCCEEDED(enumerator->HasMoreElements(&hasMore)) >+ && hasMore){ >+ nsCOMPtr<nsISupports> isupports; >+ rv = enumerator->GetNext(getter_AddRefs(isupports)); >+ >+ nsCOMPtr<nsIPresentationDevice> device(do_QueryInterface(isupports)); >+ MOZ_ASSERT(device); >+ >+ nsAutoCString id; >+ if (NS_SUCCEEDED(device->GetId(id)) >+ && id.Equals(utf8DeviceId)) { Nit, I'd put && at the end of previous line >@@ -38,24 +38,27 @@ interface nsIPresentationService : nsISu update uuid of this interface >+function testStartConnectionWithDevice() { >+ return new Promise(function(aResolve, aReject) { >+ gScript.addMessageListener('device-prompt', function devicePromptHandler() { >+ gScript.removeMessageListener('device-prompt', devicePromptHandler); >+ ok(false, "Device prompt should not be triggered."); Should we still remove the listener even if this doesn't get called? Or do we somehow manage to not leak here. >+ * A chrome page uses startWithDevice() chrome page, or page which has presentation-device-manage permissiongs
Attachment #8707394 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #2) > Comment on attachment 8707394 [details] [diff] [review] > start-with-device-api.patch > > >+ while(NS_SUCCEEDED(enumerator->HasMoreElements(&hasMore)) > >+ && hasMore){ > >+ nsCOMPtr<nsISupports> isupports; > >+ rv = enumerator->GetNext(getter_AddRefs(isupports)); > >+ > >+ nsCOMPtr<nsIPresentationDevice> device(do_QueryInterface(isupports)); > >+ MOZ_ASSERT(device); > >+ > >+ nsAutoCString id; > >+ if (NS_SUCCEEDED(device->GetId(id)) > >+ && id.Equals(utf8DeviceId)) { > Nit, I'd put && at the end of previous line I realized that there is enough space if we put it in one line. fixed by merging it into one line. > > >@@ -38,24 +38,27 @@ interface nsIPresentationService : nsISu > update uuid of this interface fixed. > > > >+function testStartConnectionWithDevice() { > >+ return new Promise(function(aResolve, aReject) { > >+ gScript.addMessageListener('device-prompt', function devicePromptHandler() { > >+ gScript.removeMessageListener('device-prompt', devicePromptHandler); > >+ ok(false, "Device prompt should not be triggered."); > Should we still remove the listener even if this doesn't get called? > Or do we somehow manage to not leak here. gScript.destroy() at teardown procedure will remove the listener. > > >+ * A chrome page uses startWithDevice() > chrome page, or page which has presentation-device-manage permissiongs fixed.
Assignee | ||
Comment 4•9 years ago
|
||
rebase to m-c and update according to review comments, carry r+.
Attachment #8707394 -
Attachment is obsolete: true
Attachment #8707710 -
Flags: review+
Assignee | ||
Comment 5•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fe0280331c94
Assignee | ||
Updated•9 years ago
|
Keywords: checkin-needed
Comment 7•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/802b5a1ad701
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•