Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[SeaMonkey 2.1, mochitest-browser-chrome] browser_522545.js | sessionstore got correct userTypedValue - Got example.org, expected mozilla.org

RESOLVED FIXED in seamonkey2.1b1

Status

SeaMonkey
Session Restore
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Robert Kaiser, Assigned: neil@parkwaycc.co.uk)

Tracking

(Blocks: 1 bug, {intermittent-failure})

Trunk
seamonkey2.1b1
intermittent-failure
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sm-perma][cc-orange])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1282499502.1282502435.6363.gz

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/suite/common/tests/browser/browser_522545.js | sessionstore got correct userTypedValue - Got example.org, expected mozilla.org

Something's wrong in our own court in this test. :(

Comment 1

7 years ago
I'm pretty sure I saw this before my userTypedValue patch landed.

Comment 2

7 years ago
The bug was opened before Your patch landed ;)

Comment 3

7 years ago
Created attachment 470280 [details] [diff] [review]
clear existing tabs cache befor using them

I don't know why Firefox didn't hit this, but problem is that _collectTabData returns cached data of tab yet to be loaded. Suppose sessionstore opened a tab and cached it's data until load event indicates it's loaded. So if you call getbrowserstate ss actually returns a cached state of a tab. But if you do setbrowserstate before tab loaded and do getbrowserstate before new one loaded, ss will return cache of previous state. Maybe it's somehow related with SM specific "load" and "pageshow" event processing, or empty browser state which this test trying to set triggering this. Anyhow, this patch explicitly clears the cache of tab being reused.
Assignee: nobody → misak.bugzilla
Status: NEW → ASSIGNED
Attachment #470280 - Flags: superreview?(neil)
Attachment #470280 - Flags: review?(neil)
(Assignee)

Comment 4

7 years ago
Created attachment 470309 [details] [diff] [review]
Actually allow the load event to fire

I don't think we're allowing the load event to fire. This should fix that.
Assignee: misak.bugzilla → neil
Attachment #470280 - Attachment is obsolete: true
Attachment #470309 - Flags: review?(misak.bugzilla)
Attachment #470280 - Flags: superreview?(neil)
Attachment #470280 - Flags: review?(neil)

Comment 5

7 years ago
Comment on attachment 470309 [details] [diff] [review]
Actually allow the load event to fire

Oh, how simple ...
This rises another question - why firefox pass this test ?
Attachment #470309 - Flags: review?(misak.bugzilla) → review+
(Assignee)

Comment 6

7 years ago
Pushed changeset dca910b78975 to comm-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Target Milestone: --- → seamonkey2.1b1
Comment hidden (Treeherder Robot)
Keywords: intermittent-failure
Whiteboard: [sm-perma][orange] → [sm-perma]

Updated

5 years ago
Whiteboard: [sm-perma] → [sm-perma][cc-orange]
You need to log in before you can comment on or make changes to this bug.