[Accepted with Revisions] SDL 0273 - WebEngine Projection mode

[theresalech]

Hello SDL community,

The review of the revised "SDL 0273 - WebEngine Projection mode" proposal begins now and runs through May 19, 2020. Previous reviews of this proposal occurred January 15 - February 25, 2020, and March 24 - April 28, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0273-webengine-projection-mode.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/912

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

[theresalech]

The author has revised the proposal to include the Steering Committee's requested revisions, and the revised proposal will now be in review until May 19, 2020. The specific changes made to the proposal since its last review can be viewed in this merged PR: https://github.com/smartdevicelink/sdl_evolution/pull/996.

[joeljfischer]

Forgive me if I'm not numbering correctly.

15. You state:

The WEB_VIEW template is not allowed to to support textfields, softbuttons, graphics (inside or outside of the webview). DuplicateUpdatesFromWindowID=0 is not allowed for widgets.

How will this work? If an app registers with web view, navigates to a different template, creates a widget to duplicate content, then go back to the web view, will that work? Are all apps with HMI type WEB_VIEW not allowed to use duplicating widgets?

[joeljfischer]

16. I think this paragraph may need some clarification:

The HMI should include a button to access the app list, the add command menu button (or a requirement for the app to implement ShowAppMenu or otherwise implement CloseApplication), and app/template title. The template/app title should be visible when the app is activated. The exact location of the template/app title relies on the OEM.

I would rewrite some of the language as follows:

The HMI must include a button to access the app list, the add command menu button (or a requirement for the app to implement ShowAppMenu or otherwise implement CloseApplication), and should (but is not required to) include the app title and or the template title text field. If included, the template/app title should be visible when the app is activated. The exact location of the these UI elements is dependent on the OEM, but they must never overlay the WebView template and must be present around the outside of the app's customizable area.

17. Stylistically, the proposal should use backticks to mark all RPC names, e.g. AddCommand.

18. I would request an addition to this line:

If the app has sent any AddCommands or AddSubmenus, then the MENU button should appear but must not overlay the app's content.

19. This passage conflicts with an earlier passage which I noted in (15):

Widgets are not affected by this proposal. They are still available and can be controlled using Show RPC. Any overlay like Alert, ChoiceSets, Slider etc. are also available to the application.

Widgets that duplicate content from the main window should still be possible.

20. I think this passage needs updating:

The HMI type WEB_VIEW should be policy controlled.

It should probably say "for head units that use policies"

21. Please remove the following section from the proposed solution unless you wish to begin the 3rd party app discussion now:

At the time of this proposal being in review, a set of driver distraction rules are being created and proposed to enable 3rd party using the projection mode. The following bullet points are items that will be described further in the ruleset

and the following bullet points.

22. Please mark the potential downsides with numbers to help follow which are different from others. Are there one or two downsides there.

23. The impact section doesn't seem to be accurate:

As a new enum element is added to the AppHMIType enum, other platforms are impacted by this very minor change. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. Possibly SDL Server and SHAID are affected as HMI types are part of the policy system.

I would recommend the following:

Additional enum elements have been added to the MOBILE and HMI APIs. This means there will be a minor version change to all app library platforms, and Core. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. SDL Server and SHAID are affected as HMI types are part of the policy system.

[AByzhynar]

Forgive me if I'm not numbering correctly.

15. You state:

The WEB_VIEW template is not allowed to to support textfields, softbuttons, graphics (inside or outside of the webview). DuplicateUpdatesFromWindowID=0 is not allowed for widgets.

How will this work? If an app registers with web view, navigates to a different template, creates a widget to duplicate content, then go back to the web view, will that work? Are all apps with HMI type WEB_VIEW not allowed to use duplicating widgets?

15. @joeljfischer Let's divide it into 2 parts. It's easier to reply in this case. 1. How will this work? If an app registers with web view, navigates to a different template, creates a widget to duplicate content, then go back to the web view, will that work?

• Yes. The duplicate widgets should continue to operate normally. The app is able to send content to the main (default) window but this content will be shown on duplicating widgets only, not on the main window as the WEB_VIEW template is active on the main window. This is aligned with the behavior of existing templates (ie switching from NON_MEDIA to a TILES_ONLY template with a duplicate widget)

It looks that the phrase DuplicateUpdatesFromWindowID=0 is not allowed for widgets. is confusing. Let's rephrase it to be more specific:

If the app has an active "WEB_VIEW" template, it is not allowed to create widgets with the option "DuplicateUpdatesFromWindowID=0", but it is still allowed to use such widgets if they were created while the app had different active templates. The content sent to the main window won't be shown on the "WEB_VIEW" but is will be shown on the widgets duplicating the main window If you have a better idea how to rephrase, I will be appreciated for the options.

2. Are all apps with HMI type WEB_VIEW not allowed to use duplicating widgets? Maybe it is just small confusion. The proposal is about new App HMI type WEB_VIEW and a new HMI template with the same name WEB_VIEW. This is the default template for apps with app HMI type WEB_VIEW. So the answer to your question:
   • No. All apps are allowed to use duplicating widgets including the apps with HMI type WEB_VIEW. The apps with HMI type WEB_VIEW can have different templates on the HMI. They just can not create duplicating widgets when they have active template WEB_VIEW. When they have a different template - they are allowed to create this type of widgets and use them. So this restriction works only for the active WEB_VIEW template.

[AByzhynar]

16. I think this paragraph may need some clarification:

The HMI should include a button to access the app list, the add command menu button (or a requirement for the app to implement ShowAppMenu or otherwise implement CloseApplication), and app/template title. The template/app title should be visible when the app is activated. The exact location of the template/app title relies on the OEM.

I would rewrite some of the language as follows:

The HMI must include a button to access the app list, the add command menu button (or a requirement for the app to implement ShowAppMenu or otherwise implement CloseApplication), and should (but is not required to) include the app title and or the template title text field. If included, the template/app title should be visible when the app is activated. The exact location of the these UI elements is dependent on the OEM, but they must never overlay the WebView template and must be present around the outside of the app's customizable area.

@joeljfischer

16. Could you be so kind and clarify the expected functionality from "Add command menu" button? Is it the same as the already described "MENU" button in the proposal here: Menu button ? If yes, why do we need both of them? Looks that this part is completely covered by the chapter in the link above.

We can just rephrase the following part that you proposed:

`The HMI also should include:

• a button to access the app list
• the app title and or the template title text field(should but is not required to). If included, the template/app title should be visible when the app is activated. The exact location of the these UI elements is dependent on the OEM, but they must never overlay the WebView template and must be present around the outside of the app's customizable area.`

[AByzhynar]

@joeljfischer Please check the answers below.

17. Stylistically, the proposal should use backticks to mark all RPC names, e.g. AddCommand.

Thank you. Agree.

18. I would request an addition to this line:

If the app has sent any AddCommands or AddSubmenus, then the MENU button should appear but must not overlay the app's content.

Thank you. Agree.

19. This passage conflicts with an earlier passage which I noted in (15):

Widgets are not affected by this proposal. They are still available and can be controlled using Show RPC. Any overlay like Alert, ChoiceSets, Slider etc. are also available to the application.

Widgets that duplicate content from the main window should still be possible.

Please consider the answer to 15: https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-630126513 If you still see the conflicts, please leave the details. Thank you.

20. I think this passage needs updating:

The HMI type WEB_VIEW should be policy controlled.

It should probably say "for head units that use policies"

As far as I understand the entire functionality of webengine apps depends on the policies. I am not sure that this functionality is available without the policies. Please see the initial WebEngine proposal HMI API extension

[AByzhynar]

21. Please remove the following section from the proposed solution unless you wish to begin the 3rd party app discussion now:

At the time of this proposal being in review, a set of driver distraction rules are being created and proposed to enable 3rd party using the projection mode. The following bullet points are items that will be described further in the ruleset

and the following bullet points.

Ok. We agree to remove this part.

22. Please mark the potential downsides with numbers to help follow which are different from others. Are there one or two downsides there.

It’s ok to bullet point here. The suggestion:

1. The same downsides apply as for SDL 0031 Mobile Projection because WebEngine applications that use the web view are responsible just as any projection or mobile navigation application.
2. The proposal states: If a WebEngine application attempts to register with this HMI type but the local policy table doesn’t allow, Core should not allow the app to register. This can be seen as a downside as it could break with apps being used for the first time. This feature would require the IVI to implement policy table updates through the vehicle modem instead of using a mobile application. It also requires the HMI to use SetAppProperties upon app installation to add the app policy ID to the policy table in order to trigger the policy table update through the mode.

23. The impact section doesn't seem to be accurate:

As a new enum element is added to the AppHMIType enum, other platforms are impacted by this very minor change. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. Possibly SDL Server and SHAID are affected as HMI types are part of the policy system.

I would recommend the following:

Additional enum elements have been added to the MOBILE and HMI APIs. This means there will be a minor version change to all app library platforms, and Core. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. SDL Server and SHAID are affected as HMI types are part of the policy system.

Agree. We will rephrase this chapter. Thank you.

[theresalech]

The Steering Committee voted to keep this proposal in review, to allow the PM to respond to the latest comments from the author and for the conversation to continue as needed on the review issue.

[joeljfischer]

15. I think this is where my confusion stems from:

The content sent to the main window won't be shown on the "WEB_VIEW" but is will be shown on the widgets duplicating the main window

If a Show is sent to an app with TILES_ONLY but the widget supports a text field, sending a Show with textField1 will show the text on the widget but not the main screen? The app libraries restrict such a case. I vaguely remember us discussing that issue internally at Livio now. If this is all incredibly confusing for a maintainer at Livio, I can only imagine that it would be even more confusing for an HMI developer or app developer. If this could be clearly laid out in the proposal, I would be grateful.

They just can not create duplicating widgets when they have active template WEB_VIEW. When they have a different template - they are allowed to create this type of widgets and use them. So this restriction works only for the active WEB_VIEW template.

This is the other source of confusion. I thought we were trying to do no / absolutely minimal changes to Core for widgets / WEB_VIEW, which I would assume means that widgets either (1) don't allow duplicating for any app HMI type WEB_VIEW or (2) allow duplicating even if it's not going to work. I think that (1) is how I had interpreted PM's item 14:

(Item 14) Author to specify that we will not allow any webview template to support textfields, softbuttons, graphics (inside or outside of the webview). DuplicateUpdatesFromWindowID=0 is not allowed for widgets.

Maybe @JackLivio or @joeygrover can help me understand what the intention of 14 was, because it seems vaguely worded.

16. You state:

Could you be so kind and clarify the expected functionality from "Add command menu" button?

That's a quote directly from your proposal. I assumed it meant the menu button to show the app's main menu. Whether you meant that or something else, I would appreciate clarification in the proposal itself, but I do think that it is important to mention the menu button, because the proposal you link to still is a template-based proposal, not a WEB_VIEW template proposal. What I'm asking for is clarification for HMI developers implementing the WEB_VIEW template. For that reason, I disagree with the language you proposed.

19. In the proposal in one section you state how widgets with DuplicateContent are handled differently, but here, as I quote you state:

Widgets are not affected by this proposal.

That appears to be a contradiction to me.

20. @JackLivio can you weigh in here? We have members who don't use policies, so restricting this feature to policies-only doesn't seem correct.

22. That looks okay to me.

[AByzhynar]

16. You state:

Could you be so kind and clarify the expected functionality from "Add command menu" button?

That's a quote directly from your proposal. I assumed it meant the menu button to show the app's main menu. Whether you meant that or something else, I would appreciate clarification in the proposal itself, but I do think that it is important to mention the menu button, because the proposal you link to still is a template-based proposal, not a WEB_VIEW template proposal. What I'm asking for is clarification for HMI developers implementing the WEB_VIEW template. For that reason, I disagree with the language you proposed.

@joeljfischer this statement initially came from this comment (requested by @theresalech) : https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-620763059 Item # 11. But now I can see that "MENU" button description is enough. That's why I would like to clarify what "Add command menu" button means. So if it is the same as "Menu" button, it can be safely removed from the proposal. If it's required - I would be glad to discuss it again to get the same understanding.

[AByzhynar]

15. I think this is where my confusion stems from:

The content sent to the main window won't be shown on the "WEB_VIEW" but is will be shown on the widgets duplicating the main window

If a Show is sent to an app with TILES_ONLY but the widget supports a text field, sending a Show with textField1 will show the text on the widget but not the main screen? The app libraries restrict such a case. I vaguely remember us discussing that issue internally at Livio now. If this is all incredibly confusing for a maintainer at Livio, I can only imagine that it would be even more confusing for an HMI developer or app developer. If this could be clearly laid out in the proposal, I would be grateful.

I would be glad to discuss it again to get the same understanding. The current behavior: The content sent in Show request to the main window is saved internally by the HMI independently of the current active template on the main window. So if the active template is TILES_ONLY and the app Sends Show with some text fields, the HMI saves the received text fields but did not show them. When the app changes the active template to the other one with the support of text fields, the HMI shows text fields received beforehand. The initial (before the one described above) idea was to reject Show requests sent to main window while it has active template WEB_VIEW.

Show requests that address the main window won't have any effect on the HMI. If the app sends this request, Core should return an unsuccessful response with the result code RESOURCE_NOT_AVAILABLE. But it makes the flow more complicated. SDL should not reject all show requests as only Show request can change the active app template. So some Show requests to the main window should be rejected while other Show requests should successfully proceed. Another way to control this flow is using display capabilities. If the head unit does not support show requests for a webengine app, the display capabilities will let the app know. It is not necessary to say webengine apps cannot send Shows when that information can be propagated to the app by the head unit's declaration that those fields are not supported for the main window or the selected template. Here I can see a problem that WindowCapabilties are window specific, not template specific. So if HMI sends to the main window list of available templates as well as text fields available for window (so for all templates supported by this window), which leads us to support provided text fields on all templates available on the specified window.

  <struct name="WindowCapability">
    <param name="windowID" type="Integer" mandatory="false">
      <description>
        The specified ID of the window. Can be set to a predefined window,
        or omitted for the main window on the main display.
      </description>
    </param>
    <param name="textFields" type="TextField" minsize="1" maxsize="100" array="true" mandatory="false">
      <description>A set of all fields that support text data. See TextField</description>
    </param>
    <param name="imageFields" type="ImageField" minsize="1" maxsize="100" array="true" mandatory="false">
      <description>A set of all fields that support images. See ImageField</description>
    </param>
    <param name="imageTypeSupported" type="ImageType" array="true" minsize="0" maxsize="1000" mandatory="false">
      <description>Provides information about image types supported by the system.</description>
    </param>
    <param name="templatesAvailable" type="String" minsize="0" maxsize="100" maxlength="100" array="true" mandatory="false">
      <description>A set of all window templates available on the head unit.</description>
    </param>

Then in the comment https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-610583779 Livio team proposed new options:

13b/14. We disagree with the expected behavior for cases 1.1 and 1.3. We are proposing two options:

1. If a webview template supports textfields, that means the textfields should be rendered on screen, but outside of the webview. DuplicateUpdatesFromWindowID=0 is allowed in this case.

2. Do not allow any webview template to support textfields, softbuttons, graphics (outside of the webview). DuplicateUpdatesFromWindowID=0 is not allowed for widgets.

Option 2 would reduce the amount of complexity for developers by making clear that those textfields and imagefields will never be available and therefore the developer doesn't need to create a lot of extra code to account for them. This option would also prevent fragmentation among OEM implementations of this feature.

The option 2 looks better. So we added it to the proposal. DuplicateUpdatesFromWindowID=0 is a parameter in CreateWindow request, so it is not allowed to create widgets with this option while the app has the active WEB_VIEW template. The app still can create such widgets while having the other active template. The new question appeared: what to do with the widgets created by the app while having a template other than WEB_VIEW, then app changes its template to WEB_VIEW? Then in the comment: https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-620763059 it was proposed: (Item 13b) Author to update the proposal to reflect that the behavior of the WEB_VIEW template with duplicate widgets should align with the behavior of existing templates (ie switching from NON_MEDIA to a TILES_ONLY template with a duplicate widget). @joeljfischer Please post your opinion. Thank you. Ready for discussion.

[Jack-Byrne]

15.

To reiterate on parts of @AByzhynar comment:

The content sent in Show request to the main window is saved internally by the HMI independently of the current active template on the main window. So if the active template is TILES_ONLY and the app Sends Show with some text fields, the HMI saves the received text fields but did not show them. When the app changes the active template to the other one with the support of text fields, the HMI shows text fields received beforehand.

This part is all correct to my understanding of how HMI should implement the Show rpc. This existing behavior is why WEB_VIEW should be able to receive show requests even without text fields, and be able to update previously created duplicate widgets. Even if the managers wont let this case happen, thats fine, we just wanted to preserve existing behavior for Show.

The goal to keep things simple was to try and not change widgets behavior at all for this proposal. The one exception in this proposal for widgets is that WEB_VIEW should not be able to create a duplicate widget from the main window.

[theresalech]

Hi @AByzhynar, I've summarized the status of comments below, with feedback from the PM on the open items:

Open Items 16. I think that this item still needs to be included in this proposal and not removed. This is a different proposal to the WebEngine one; this proposal is specifically about the WebView template and I fear that if this requirement is not included in the proposal then somebody implementing it will miss the requirement.

19. Given https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0273-webengine-projection-mode.md#1-template-web_view, please remove "Widgets are not affected by this proposal." from https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0273-webengine-projection-mode.md#13-what-about-widgets.

Author to Update 17. Author to use backticks throughout proposal to mark all RPC names, e.g. AddCommand.

18. Author to update following line:

If the app has sent any AddCommands or AddSubmenus, then the MENU button should appear but must not overlay the app's content.

21. Author to remove the following:

At the time of this proposal being in review, a set of driver distraction rules are being created and proposed to enable 3rd party using the projection mode. The following bullet points are items that will be described further in the ruleset

22. Author to add bullets to Potential downsides section:

• The same downsides apply as for SDL 0031 Mobile Projection because WebEngine applications that use the web view are responsible just as any projection or mobile navigation application.

• The proposal states: If a WebEngine application attempts to register with this HMI type but the local policy table doesn’t allow, Core should not allow the app to register. This can be seen as a downside as it could break with apps being used for the first time. This feature would require the IVI to implement policy table updates through the vehicle modem instead of using a mobile application. It also requires the HMI to use SetAppProperties upon app installation to add the app policy ID to the policy table in order to trigger the policy table update through the mode.

23. In Impact on existing code section, author to change

As a new enum element is added to the AppHMIType enum, other platforms are impacted by this very minor change. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. Possibly SDL Server and SHAID are affected as HMI types are part of the policy system.

to

Additional enum elements have been added to the MOBILE and HMI APIs. This means there will be a minor version change to all app library platforms, and Core. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. SDL Server and SHAID are affected as HMI types are part of the policy system.

Closed/No Action Required 20. We understand, and are in agreement with no further changes required for this item.

[AByzhynar]

16. I think that this item still needs to be included in this proposal and not removed. This is a different proposal to the WebEngine one; this proposal is specifically about the WebView template and I fear that if this requirement is not included in the proposal then somebody implementing it will miss the requirement.

@theresalech 16. Could you be so kind and clarify the expected functionality from "Add command menu" button on the HMI? Is it the same as the already described "MENU" button in the proposal here? If yes, why do we need both of them? Thank you

[joeljfischer]

@AByzhynar 16. It is the menu button you describe. I think that the statement should continue to include it in order to have the full list of required buttons in one place. It's fine to then expand upon the menu button in the App Deactivation section you mentioned.

[AByzhynar]

@joeljfischer Thank you. Now it is clear. I just would like to propose to name it “MENU” button (or “App Menu” ), but the same name should be used everywhere in the proposal to avoid confusion. Don’t you mind?

[joeljfischer]

@AByzhynar I think that sounds like a good change. Maybe you should define it in parenthesis the first time it’s used? It should be obvious, I just want to avoid confusion between that button and one the developer makes themselves using the WEB_VIEW.

Something like

“MENU (the button that shows the list of AddCommand and AddSubmenu items)”

[theresalech]

The Steering Committee voted to keep this proposal in review, to allow the PM and author to resolve the remaining open items in discussion (16 and 19).

[kshala-ford]

@AByzhynar and I came up with a conclusion to 16 and 19. Both are very closely related to 15 and 18 which is why we decided to use a title instead. We're OK with new numbers (24, 25) if further discussion is needed but we try to provide a complete statement to both (actually all four) items:

---

16. & 18. App Menu

We want to make everyone aware of the accepted proposal SDL-0116 Open Menu which added a new RPC called ShowAppMenu (see proposal) This proposal states the following:

The proposed solution is to specify the built-in "menu" button to not exist anymore at all for projection apps. Instead those apps should be allowed to send a request to show the built-in menu view.

and

Projection apps should project a button which the user can press. The app would react on this button press and send the ShowAppMenu request.

Apps which show content using WEB_VIEW have the same responsibilities than projection apps therefore the same requirement applies to WebEngine apps. We suggest to add the following items to the proposal in favor of showing a menu button on the HMI:

1. The HMI should include an app title and a template title. The template/app title should be visible when the app is activated. The exact location of the template/app title relies on the OEM.
2. The HMI should include a button to access the app list
3. The HMI should not show a menu button on the HMI. Instead the app should be required to behave as followed:
   1. If the app uses AddCommand or AddSubMenu the app is required to provide an own menu button on the WEB_VIEW and send ShowAppMenu if this menu button is selected by the user.
      2. If the app does not use commands or sub menus the app is required to provide a way to the user to exit the application. The app should use CloseApplication RPC for this.

---

15. & 19. Related to widgets and duplicate content

With regards to widgets we think that the statement that's currently in the proposal DuplicateUpdatesFromWindowID=0 is not allowed for widgets. is weak. As already commented the developer can change to a template layout, add the duplicating widget and turn back to WEB_VIEW very easily. Therefore we suggest to remove this statement from the proposal.

The section What about widgets? is correct and accurate to the current behavior of Core. The behavior of the libraries is to be seen separately and also affects mobile navigation/projection apps and should be revisited separately from this proposal. This aligns with Jack's comment here.

Our suggestion is not to change the behavior of how SDL Core is duplicating content. The section What about widgets? already makes this suggestion.

[AByzhynar]

21. Author to remove the following:

At the time of this proposal being in review, a set of driver distraction rules are being created and proposed to enable 3rd party using the projection mode. The following bullet points are items that will be described further in the ruleset

@theresalech The enabling of 3rd party apps is a long term goal which we hope to enable with a future proposal. We would like to keep it in the proposal, but move to the motivation section

At the time of this proposal being in review, 
a set of driver distraction rules are being created and proposed to have 
the possibility to enable 3rd party using the projection mode in the future. 
The following bullet points are items that will be described further in the ruleset:

- minimum font size
- minimum contrast between font and background
- min/max brightness (for day and night mode)
- number of buttons
- minimum size of a button
- no customized keyboard
- no video playback (exceptions in standstill per countries)
- NHTSA related guidelines
    - Amount of text (button and text fields)
    - number of lines of text
    - Complexity of use cases (number of steps to fulfill a use case)

More items may be included in the ruleset as they become Driver Distraction affected.

[AByzhynar]

@theresalech Let's assign a new number : 26 to the current item.

We consider that

  The WEB_VIEW template is not allowed to to support textfields, softbuttons, graphics (inside or outside of the webview).

is not accurate enough and should be changed to :

The WEB_VIEW template must be designed without support showing the content of the Show RPC like textfields, softbuttons, graphics (inside or outside of the webview).

[AByzhynar]

@theresalech The changes proposed in 16. & 18 here: https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-635317778 will also require to remove application deactivation section

[theresalech]

Hi @AByzhynar and @kshala-ford, thanks for your feedback. We are okay with your suggestions for 24 and 25. I've included an updated status of comments below, with feedback from the PM on the open items:

Open Items 21. This proposal is specific to OEM applications, and therefore this motivation is out of scope for the proposal and should be removed.

26. We'd recommend

The WEB_VIEW template must not declare support in its WindowCapabilities for any softButtonCapabilities, the TextFields with name: mainField1-4, mediaClock, mediaTrack, nor the ImageFields with name: softButtonImage, menuIcon, graphic, or secondaryGraphic.

Author to Update 17. Author to use backticks throughout proposal to mark all RPC names, e.g. AddCommand.

22. Author to add bullets to Potential downsides section:

• The same downsides apply as for SDL 0031 Mobile Projection because WebEngine applications that use the web view are responsible just as any projection or mobile navigation application.

• The proposal states: If a WebEngine application attempts to register with this HMI type but the local policy table doesn’t allow, Core should not allow the app to register. This can be seen as a downside as it could break with apps being used for the first time. This feature would require the IVI to implement policy table updates through the vehicle modem instead of using a mobile application. It also requires the HMI to use SetAppProperties upon app installation to add the app policy ID to the policy table in order to trigger the policy table update through the mode.

23. In Impact on existing code section, author to change

As a new enum element is added to the AppHMIType enum, other platforms are impacted by this very minor change. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. Possibly SDL Server and SHAID are affected as HMI types are part of the policy system.

to

Additional enum elements have been added to the MOBILE and HMI APIs. This means there will be a minor version change to all app library platforms, and Core. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. SDL Server and SHAID are affected as HMI types are part of the policy system.

24 (formerly 16 and 18). Author to add the following items to the proposal in favor of showing a menu button on the HMI:

1. The HMI should include an app title and a template title. The template/app title should be visible when the app is activated. The exact location of the template/app title relies on the OEM.
2. The HMI should include a button to access the app list
3. The HMI should not show a menu button on the HMI. Instead the app should be required to behave as followed:
   1. If the app uses AddCommand or AddSubMenu the app is required to provide an own menu button on the WEB_VIEW and send ShowAppMenu if this menu button is selected by the user.
      2. If the app does not use commands or sub menus the app is required to provide a way to the user to exit the application. The app should use CloseApplication RPC for this.

The application deactivation section will also be removed.

25 (formerly 15 and 19). Author to remove DuplicateUpdatesFromWindowID=0 is not allowed for widgets. Behavior of how Core is duplicating content will not change, so the What about widgets? section can remain as is.

Closed/No Action Required 20. We understand, and are in agreement with no further changes required for this item.

[AByzhynar]

21. This proposal is specific to OEM applications, and therefore this motivation is out of scope for the proposal and should be removed.

We agree to remove it but our long term goal is still valid for the future proposals.

[theresalech]

Hi @AByzhynar, can you please advise if you are okay with our suggestion for Item 26?

[AByzhynar]

@theresalech All the changes proposed by you in https://github.com/smartdevicelink/sdl_evolution/issues/912#issuecomment-635565239, including item 26, are included in the new revision. PR with the new revision: https://github.com/smartdevicelink/sdl_evolution/pull/1023 So we are okay with all the proposed changes. Thank you.

[theresalech]

In preparation for today's Steering Committee meeting, I have summarized the revisions the PM and author have agreed upon below. Unless there are any other comments from members, we'll ask the Steering Committee to vote to accept the proposal with the revisions below:

17. Author to use backticks throughout proposal to mark all RPC names, e.g. AddCommand.

21. Author to remove the following

At the time of this proposal being in review, a set of driver distraction rules are being created and proposed to enable 3rd party using the projection mode. The following bullet points are items that will be described further in the ruleset

22. Author to add bullets to Potential downsides section:

• The same downsides apply as for SDL 0031 Mobile Projection because WebEngine applications that use the web view are responsible just as any projection or mobile navigation application.

• The proposal states: If a WebEngine application attempts to register with this HMI type but the local policy table doesn’t allow, Core should not allow the app to register. This can be seen as a downside as it could break with apps being used for the first time. This feature would require the IVI to implement policy table updates through the vehicle modem instead of using a mobile application. It also requires the HMI to use SetAppProperties upon app installation to add the app policy ID to the policy table in order to trigger the policy table update through the mode.

23. In Impact on existing code section, author to change

As a new enum element is added to the AppHMIType enum, other platforms are impacted by this very minor change. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. Possibly SDL Server and SHAID are affected as HMI types are part of the policy system.

to

Additional enum elements have been added to the MOBILE and HMI APIs. This means there will be a minor version change to all app library platforms, and Core. Core would need to specially treat apps with this HMI type as they are not allowed to register unless permission was granted. SDL Server and SHAID are affected as HMI types are part of the policy system.

24 (formerly 16 and 18). Author to add the following items to the proposal in favor of showing a menu button on the HMI:

1. The HMI should include an app title and a template title. The template/app title should be visible when the app is activated. The exact location of the template/app title relies on the OEM.
2. The HMI should include a button to access the app list
3. The HMI should not show a menu button on the HMI. Instead the app should be required to behave as followed:
4. If the app uses AddCommand or AddSubMenu the app is required to provide an own menu button on the WEB_VIEW and send ShowAppMenu if this menu button is selected by the user.
5. If the app does not use commands or sub menus the app is required to provide a way to the user to exit the application. The app should use CloseApplication RPC for this.

The application deactivation section will also be removed.

25 (formerly 15 and 19). Author to remove DuplicateUpdatesFromWindowID=0 is not allowed for widgets. Behavior of how Core is duplicating content will not change, so the What about widgets? section can remain as is.

26. Author to update

The WEB_VIEW template is not allowed to to support textfields, softbuttons, graphics (inside or outside of the webview).

to

The WEB_VIEW template must not declare support in its WindowCapabilities for any softButtonCapabilities, the TextFields with name: mainField1-4, mediaClock, mediaTrack, nor the ImageFields with name: softButtonImage, menuIcon, graphic, or secondaryGraphic.

[theresalech]

The Steering Committee voted to accept this proposal with the revisions outlined in this comment.

[theresalech]

Author has updated proposal to reflect agreed upon revisions, and implementation issues have been entered:

• RPC
• Core
• SDL HMI
• Generic HMI
• iOS
• Java Suite
• JavaScript Suite
• Server