Bug 1564436 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

After discussed with Anne, I think the current conclusion is this bug is still a blocker for Background Sync API.
Permission prompt for offline-sync-registration seems not to be an acceptable solution, since followings
    1. Prompt is annoying. Most users always click close or denied it directly, and doesn't care about what it describes.
    2. Even for the users cares the prompt description, it is hard to explain to users what the permission is. Because we can only tell users is the website wants to do something in background once backs to online.

So we need another solution.

Anne told me that Background Fetch API UI might be a possible solution for the Background Sync API. Where the spec: https://wicg.github.io/background-fetch. It describes a UI for background fetch and how the UI interacts with users and websites.

I just took a look at the spec quickly. I am not sure if the UI is also suitable BackgroundSync API since the UI postpones the user decision to the timing when dispatching or handling the sync event. Sync actions might not like fetching can be dropped or canceled easy. Canceling the sync action could make problems because users might expect all the things are done when they close the tab or navigate to another website.

If we want to apply a UI solution for Background Sync, we need to update its rules on the spec, since to support UI solution, we probably also need to interact with websites.
After discussed with Anne, I think the current conclusion is this bug is still a blocker for Background Sync API.
Permission prompt for offline-sync-registration seems not to be an acceptable solution, since followings

    1. Prompt is annoying. Most users always click close or denied it directly, and doesn't care about what it describes.
    2. Even for the users cares the prompt description, it is hard to explain to users what the permission is. Because we can only tell users is the 
website wants to do something in background once backs to online.

So we need another solution.

Anne told me that Background Fetch API UI might be a possible solution for the Background Sync API. Where the spec: https://wicg.github.io/background-fetch. It describes a UI for background fetch and how the UI interacts with users and websites.

I just took a look at the spec quickly. I am not sure if the UI is also suitable BackgroundSync API since the UI postpones the user decision to the timing when dispatching or handling the sync event. Sync actions might not like fetching can be dropped or canceled easy. Canceling the sync action could make problems because users might expect all the things are done when they close the tab or navigate to another website.

If we want to apply a UI solution for Background Sync, we need to update its rules on the spec, since to support UI solution, we probably also need to interact with websites.
After discussed with Anne, I think the current conclusion is this bug is still a blocker for Background Sync API.
Permission prompt for offline-sync-registration seems not to be an acceptable solution, since followings

1. Prompt is annoying. Most users always click close or denied it directly, and doesn't care about what it describes.
2. Even for the users cares the prompt description, it is hard to explain to users what the permission is. Because we can only tell users is the 
website wants to do something in background once backs to online.

So we need another solution.

Anne told me that Background Fetch API UI might be a possible solution for the Background Sync API. Where the spec: https://wicg.github.io/background-fetch. It describes a UI for background fetch and how the UI interacts with users and websites.

I just took a look at the spec quickly. I am not sure if the UI is also suitable BackgroundSync API since the UI postpones the user decision to the timing when dispatching or handling the sync event. Sync actions might not like fetching can be dropped or canceled easy. Canceling the sync action could make problems because users might expect all the things are done when they close the tab or navigate to another website.

If we want to apply a UI solution for Background Sync, we need to update its rules on the spec, since to support UI solution, we probably also need to interact with websites.

Back to Bug 1564436 Comment 7