New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 647296 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

[Presentation API] PresentationReceiver should be null unless the frame is a presentation

Project Member Reported by mfo...@chromium.org, Sep 15 2016

Issue description

To match spec, navigator.presentation.receiver must be null in a browsing context that is not a presentation.

The code that constructs offscreen tabs will need to pass a flag to Blink that can be checked in Presentation.cpp where the receiver object is accessed.

Assigning to Mounir to get his input on the best way to do that.
 

 

Comment 1 by sko...@chromium.org, Sep 21 2016

Labels: Needs-Feedback
Status: Assigned (was: Untriaged)
It depends on how we setup the renderer process for the receiver. I think the easiest is to have a setting that will be enabled when creating the renderer process for the receiver.

I'm happy to the Blink changes and have someone else turn the setting on.
Labels: -Needs-Feedback M-55

Comment 4 by mfo...@chromium.org, Sep 29 2016

Labels: PresentationAPI
Labels: -M-55 M-56
Ping Mounir, will you have time to address this in M56?
mfoltz@, would it help to have this for m56? I have little visibility on how the receiver is created today. Would a runtime flag to enable receiver mode work? I assume we want presentation.receiver and PresentationReceiver to still be visible in that case, right?
zhaobin@ is implementing presentation receiver support now and can indicate whether they are blocked on this.

For non-receiver contexts in Chrome, I believe the spec requires:
- PresentationReceiver interface exists and is exposed
- navigator.presentation.receiver = null


Labels: Needs-Feedback
Ok, waiting for zhaobin@ feedback then :)

FWIW, what I had in mind is that we would pass a flag to the renderer process when created that will allow us to enable PresentationReceiver in Blink. See content/child/runtime_features.cc.
Current implementation is that we create a receiver object if none exist before when javascript calls navigator.presentation.receiver (on both controller and receiver page)

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/presentation/Presentation.cpp?rcl=1478636282&l=50

A runtime flag would certainly work and we could (I am not quite familiar with how runtime_features works):

1. have offscreen tab send a signal to render process to set the flag (is it possible to do this?)
2. have Presentation.cpp access to the runtime flag and create receiver object if flag it set
Can we enable the runtime_feature in a layout test?  This would enable testing the shape of the navigator.presentation.receiver API (otherwise it will always be null).

Labels: -Needs-Feedback
Back to Mounir.


Yes, we can test runtime flags and settings from layout tests.

The more I think about it the more I think a web preference would be better than a runtime flag. The tab should be able to set the preference. I will add the boilerplate.
That would be great.  From a discussion I just had with zhaobin@, if we could get this plumbed through to Blink and also make it accessible to presentation_dispatcher, which would make most of this patch unnecessary.

https://codereview.chromium.org/2471883002



Status: Started (was: Assigned)
I've sent https://codereview.chromium.org/2500273003
Labels: -M-56 M-57
This will likely miss M56 and I don't think we are in a rush to make it happen for this milestone. Moving to M57.
Project Member

Comment 17 by bugdroid1@chromium.org, Nov 29 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/57359d9170e32f1c8a67434b249d0b27d33dffbf

commit 57359d9170e32f1c8a67434b249d0b27d33dffbf
Author: mlamouri <mlamouri@chromium.org>
Date: Tue Nov 29 20:11:50 2016

Presentation API: add settings for presentation.receiver being exposed.

It will allow the browser process to create a renderer with the right
settings, thus exposing the presentation.receiver object.

BUG= 647296 
R=mfoltz@chromium.org

Review-Url: https://codereview.chromium.org/2500273003
Cr-Commit-Position: refs/heads/master@{#435066}

[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/content/public/common/web_preferences.cc
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/content/public/common/web_preferences.h
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/content/renderer/render_view_impl.cc
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-properties-after-frame-navigated-expected.txt
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-properties-after-frame-removed-and-gced-expected.txt
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-properties-after-frame-removed-expected.txt
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/LayoutTests/fast/dom/Window/property-access-on-cached-window-after-frame-navigated-expected.txt
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/LayoutTests/presentation/presentation-receiver.html
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/core/frame/Settings.in
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/core/testing/InternalSettings.cpp
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/core/testing/InternalSettings.h
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/core/testing/InternalSettings.idl
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/modules/presentation/Presentation.cpp
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/web/WebSettingsImpl.cpp
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/Source/web/WebSettingsImpl.h
[modify] https://crrev.com/57359d9170e32f1c8a67434b249d0b27d33dffbf/third_party/WebKit/public/web/WebSettings.h

Status: Fixed (was: Started)
Project Member

Comment 19 by bugdroid1@chromium.org, Dec 9 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f715bf8834b42c807bdcad10d18c75e503ed9a78

commit f715bf8834b42c807bdcad10d18c75e503ed9a78
Author: zhaobin <zhaobin@chromium.org>
Date: Fri Dec 09 20:59:49 2016

[Presentation API] set presentation_receiver flag in offscreen tab

 crbug.com/647296  exposes settings to control when presentation.receiver should be exposed. Set presentation_receiver flag to true and expose presentation.receiver if offscreen tab is started by presentation API.

BUG= 647296 

Review-Url: https://codereview.chromium.org/2555743008
Cr-Commit-Position: refs/heads/master@{#437647}

[modify] https://crrev.com/f715bf8834b42c807bdcad10d18c75e503ed9a78/chrome/browser/extensions/api/tab_capture/offscreen_tab.cc

Labels: -PresentationAPI

Sign in to add a comment