Session restored tbpl doesn't update its status message until you refresh




Session Restore
7 years ago
7 years ago


(Reporter: blassey, Unassigned)



Firefox Tracking Flags

(Not tracked)


The tree was closed yesterday and this morning due to bug 655197. I kept checking tbpl to see when it re-opened and it continued to show the tree as closed two hours after it apparently re-opened until I refreshed the page.

I've saw this a couple weeks ago as well, again with a morning closure. If this is not the normal behavior then perhaps its some odd interaction between tbpl and session restore (I'm running nightlies so my browser restarts for an update every morning).
Component: Release Engineering → Tinderboxpushlog
Product: → Webtools
QA Contact: release → tinderboxpushlog
Yeah, I've always been too lazy to file on the way session restore of tbpl fails in multiple directions (if you note what's the tip push when you close after having had tbpl open for hours, the restored session quite often has a tip push from hours earlier, with or without stale tinderbox data, which may or may not refresh until you force-reload the page), never really noticed the tree status since we only recently started updating it at all.
Component: Tinderboxpushlog → Session Restore
OS: Linux → All
Product: Webtools → Firefox
QA Contact: tinderboxpushlog → session.restore
Hardware: x86_64 → All
Summary: tbpl doesn't update its status message until you refresh → Session restored tbpl doesn't update its status message until you refresh
Version: other → Trunk
I thought this issue was fixed by bug 619953.
That was "tree status doesn't ever refresh, because we don't ever try to refresh it." He's saying "now that tbpl does try to refresh tree status, I updated to a new nightly while the status was closed, and my restored session restored a stuck tbpl instead of a working one so even though tbpl does have code to refresh the tree status, it didn't ever refresh in that restored tbpl."
Session restoring tbpl is a good test of pushState's interaction with session restore.  The history.state property might be useful.

I hope it works...
You need to log in before you can comment on or make changes to this bug.