Closed Bug 1270295 Opened 4 years ago Closed 4 years ago

don't update timestamps when the tab is not active / in the background

Categories

(bugzilla.mozilla.org :: User Interface, defect, major)

Production
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: dkl)

References

()

Details

(Keywords: perf, power)

Attachments

(1 file)

Bugs on https://bugzilla.mozilla.org/ (e.g., bug 1269036) are running script timeouts when they're in background tabs.  This uses a lot of CPU and battery for those of us who use bugzilla a lot and keep a bunch of bugs open in browser tabs.

This is a regression within the last few months.

The script timeouts being run is at:

https://bugzilla.mozilla.org/data/assets/1d003743cf1bd54aecc68195062b7339.js?1461679010
line 171
column 0


I'm using the experimental UI, which might make a difference here.  (I'm reasonable confident this is a regression *since* I switched to the experimental UI and not from switching to it, although I'm not 100% sure.)
Ah, the code in question is:

window.setInterval(function() {
var now = Math.floor(new Date().getTime() / 1000);
$('.rel-time').each(function() {
$(this).text(timeAgo(now - $(this).data('time')));
});
$('.rel-time-title').each(function() {
$(this).attr('title', timeAgo(now - $(this).data('time')));
});
}, 60000);


This should ideally use the page visibility API to stop the timer when the page is not visible, and run the update again (if needed) and start the timer again when the page becomes visible.

https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
Blocks: 1150541
Component: General → User Interface: Modal
Summary: bugs on bugzilla.mozilla.org run script timeouts when in background tabs → don't update timestamps when the tab is not active / in the background
Assignee: nobody → dkl
Status: NEW → ASSIGNED
Attached patch 1270295_1.patchSplinter Review
Attachment #8749398 - Flags: review?(dylan)
Comment on attachment 8749398 [details] [diff] [review]
1270295_1.patch

Review of attachment 8749398 [details] [diff] [review]:
-----------------------------------------------------------------

r- because it needs a work around: in firefox the 'hide.visibility' event is fired on page load, in dev edition anyway. Both under e10s and non-e10s.
I think we can ignore the first call maybe? Or report a bug in the jquery-visibility module.
Up to you.

The code is otherwise pleasing and it does work if you move away from the tab and back.
Attachment #8749398 - Flags: review?(dylan) → review-
(In reply to Dylan William Hardison [:dylan] from comment #3)
> Comment on attachment 8749398 [details] [diff] [review]
> 1270295_1.patch
> 
> Review of attachment 8749398 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r- because it needs a work around: in firefox the 'hide.visibility' event is
> fired on page load, in dev edition anyway. Both under e10s and non-e10s.
> I think we can ignore the first call maybe? Or report a bug in the
> jquery-visibility module.
> Up to you.
> 
> The code is otherwise pleasing and it does work if you move away from the
> tab and back.

Yes admittedly I did see similar behavior with my testing but seemed harmless as the line:

var relative_timer_id = window.setInterval(relativeTimer, relative_timer_duration);

still properly executes even after hide.visibility because $(function(){} is same as $(document).ready().

What if I did this to make it little bit clearer?

$(document).on('hide.visibility', function() {
    if (relative_timer_id)
        window.clearInterval(relative_timer_id);
});
Flags: needinfo?(dylan)
Comment on attachment 8749398 [details] [diff] [review]
1270295_1.patch

Review of attachment 8749398 [details] [diff] [review]:
-----------------------------------------------------------------

alright, I am seeing different behavior now. Perhaps a transient issue in nightly?
The timer is always added after the initial page load remove. So this works.
Attachment #8749398 - Flags: review- → review+
Flags: needinfo?(dylan)
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   6a48e02..44a2e60  master -> master
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Component: User Interface: Modal → User Interface
You need to log in before you can comment on or make changes to this bug.