Closed Bug 952259 Opened 11 years ago Closed 10 years ago

Basic automated tests for Metro sessionstore component

Categories

(Firefox for Metro Graveyard :: General, defect, P2)

All
Windows 8
defect

Tracking

(firefox28 fixed, firefox29 fixed)

RESOLVED FIXED
Firefox 29
Tracking Status
firefox28 --- fixed
firefox29 --- fixed

People

(Reporter: emtwo, Assigned: mbrubeck)

References

Details

(Whiteboard: [beta28] [defect] p=5 [qa-])

Attachments

(1 file)

It would be useful to have some kind of testing that will ensure the desktop and metro sessionstore json files are compatible with one another.

Some session store tests already exist for desktop, but not for Metro.
Whiteboard: [triage]
Whiteboard: [triage] → [release28] [defect] p=0
Assignee: nobody → mbrubeck
Blocks: metrov1it22
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Hardware: x86_64 → All
Summary: Add session store testing → Basic automated tests for Metro sessionstore component
Whiteboard: [release28] [defect] p=0 → [release28] [defect] p=5
Priority: -- → P2
QA Contact: jbecerra
Blocks: metrov1backlog
No longer blocks: metrov1it22
Blocks: metrov1it23
No longer blocks: metrov1backlog
Blocks: metrov1backlog
No longer blocks: metrov1it23
Whiteboard: [release28] [defect] p=5 → [beta28] [defect] p=5
Blocks: metrov1it23
No longer blocks: metrov1backlog
I had to make some changes to SessionStore.js to make these tests pass:

* If getBrowserState is called after a new tab is added but before its session data is initialized, it is possible to end up with a "null" value in the "tabs" array.  This is probably fairly rare in regular use, but it happens very easily in automated tests.  This patch filters out tabs that do not yet have any __SS_data.

* While running tests, I found that the _orderedWindows array was never initialized.  I suspect this was because shouldRestore was not set correctly when onWindowOpen ran.  I'm not sure whether this ever happens in regular use or only in tests, but in any case this is fixed by initializing _orderedWindows unconditionally, and resetting it if we restore a session.
Attachment #8366823 - Flags: review?(msamuel)
Comment on attachment 8366823 [details] [diff] [review]
part 1: getBrowserState tests and fixes

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

looks good! thanks for writing these tests :)
Attachment #8366823 - Flags: review?(msamuel) → review+
I'll land these and let this bug be resolved for now; we'll need more tests but I'll file separate bugs for them:
https://hg.mozilla.org/integration/fx-team/rev/1c9aee553320
Whiteboard: [beta28] [defect] p=5 → [beta28] [defect] p=5 [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/1c9aee553320
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [beta28] [defect] p=5 [fixed-in-fx-team] → [beta28] [defect] p=5
Target Milestone: --- → Firefox 29
Could you please give some guidance in order for the QA to verify this? Thanks!
Flags: needinfo?(mbrubeck)
This change should affect only automated tests, no manual verification needed.
Flags: needinfo?(mbrubeck)
Whiteboard: [beta28] [defect] p=5 → [beta28] [defect] p=5 [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: