Confirmed users
716
edits
WebAPI/IdleAPI: Difference between revisions
→Security/Privacy considerations
| Line 20: | Line 20: | ||
In order to fix this we switch to "user is idle" mode in each window with a small amount of "fuzz". I.e. we delay the switch by a few seconds or minutes. This delay is different in different tabs. This affects both the timing of when the mozUserIdle boolean changes value and when the "mozuseridle" event fires. | In order to fix this we switch to "user is idle" mode in each window with a small amount of "fuzz". I.e. we delay the switch by a few seconds or minutes. This delay is different in different tabs. This affects both the timing of when the mozUserIdle boolean changes value and when the "mozuseridle" event fires. | ||
Same thing when switching back to active mode. This | Same thing when switching back to active mode. This happens with a small randomized delay. However, if the user interacts with a tab, the page in the tab can clearly detect that the user is no longer idle. In this scenario we switch the user to active mode immediately before firing the mouse/keyboard/touch event. This *only* affects the tab the user interacted with. But if the user switches between multiple tabs, we can be forced to do this early switch in several tabs. | ||
When switching between idle/active modes, we should ideally do that for a whole tab at a time. I.e. it should affect all windows in a given tab at the same time. | When switching between idle/active modes, we should ideally do that for a whole tab at a time. I.e. it should affect all windows in a given tab at the same time. | ||
We might also want to display UI which allows the user to choose if he/she wants to expose idle/active status to page. This is something we still need to figure out. | We might also want to display UI which allows the user to choose if he/she wants to expose idle/active status to page. This is something we still need to figure out. | ||