You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For vertical-scroll demo, (similar to other policies) a sample html page is loaded inside an <iframe> where the feature itself is enabled/disabled. This is a bit limiting in demonstrating a feature such as vertical-scroll where for proper illustration, the actual <iframe>should be scrollable in its parent. Essentially with the new changes to vertical-scroll policy, when a frame is disabled it will not consume any scroll gestures. With the current demo it leads to the whole page appearing as unscrollable which is in fact only because the <iframe> containing vertical-scroll.html was not scrollable to begin with.
I think setting up for a new feature for demo-ing should involve an optional step to configure the embedding page as well. Perhaps in updatePage we could check if policy requires further tuning (although putting raw code in policy.json which is where all the feature related information coming from might not be a good idea)
The text was updated successfully, but these errors were encountered:
Yea, the iframe embedding a demo is kinda hacky. I wanted to have every page be standalone and have the server send the correct headers, but it was easier to embed the demos in an iframe and toggle policies via allow :)
I think even if the server would run and set the header to something like vertical-scroll 'none' we'd still have some issues to properly explain what the feature demos. vertical-scroll is mostly meaningful in dealing with embedded content.
I can see two solutions (there is possibly more of course):
Get sample pages apply the change to a nested<iframe>. This is basically adding an <iframe> layer which makes some preparations before loading the actual test <iframe>. Some elements such as feature-allow-banner would have to be moved to the inner most frame. The general details and policy descriptions could (optionally) stay in the middle <iframe>.
Add an embedder page initialization step which will be overridden for each policy (only vertical-scroll perhaps).
In all these two cases all we need to do for vertical-scroll is to add some spacer above or below the test frame so that it is quite visible what the feature does.
For
vertical-scroll
demo, (similar to other policies) a sample html page is loaded inside an<iframe>
where the feature itself is enabled/disabled. This is a bit limiting in demonstrating a feature such asvertical-scroll
where for proper illustration, the actual<iframe>
should be scrollable in its parent. Essentially with the new changes tovertical-scroll
policy, when a frame is disabled it will not consume any scroll gestures. With the current demo it leads to the whole page appearing as unscrollable which is in fact only because the<iframe>
containingvertical-scroll.html
was not scrollable to begin with.I think setting up for a new feature for demo-ing should involve an optional step to configure the embedding page as well. Perhaps in
updatePage
we could check if policy requires further tuning (although putting raw code inpolicy.json
which is where all the feature related information coming from might not be a good idea)The text was updated successfully, but these errors were encountered: