Closed
Bug 1239242
Opened 10 years ago
Closed 10 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•10 years ago
|
||
For any code that can access PresentationDeviceInfo API should be able to use PresentationRequest.startWithDevice().
Attachment #8707394 -
Flags: review?(bugs)
Comment 2•10 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•10 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•10 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•10 years ago
|
||
| Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Keywords: checkin-needed
Comment 7•10 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 10 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
•