The Reader View promo panel is displayed again if a crash occurred after the user viewed it

RESOLVED WORKSFORME

Status

()

Firefox
Tours
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: avaida, Assigned: Harshal Lele, Mentored)

Tracking

40 Branch
Points:
1
Bug Flags:
firefox-backlog ?
qe-verify +

Firefox Tracking Flags

(firefox38.0.5 affected, firefox39 affected, firefox40 affected)

Details

(Whiteboard: [lang=js][good first bug])

Reproducible on:
Nightly 40.0a1 (2015-04-03)

Affected platforms:
Windows 7 (x64), Ubuntu 14.04 (x64)

Steps to reproduce:
1. Launch Firefox with a clean profile.
2. Install crashme add-on - http://ted.mielczarek.org/mozilla/crashme.html
3. Open a Reader View compatible page in a new tab, e.g. http://www.bbc.com/news/world-asia-32574769
4. Close the Reader View promo panel by clicking the [x] button.
5. Wait for a few minutes (at least 2 mins), then crash Firefox using the crash-me add-on.
6. Restore the two tabs that were open before the crash, using session restore.

Expected result:
4. browser.reader.detectedFirstArticle is set to true, once the Reader View promo panel has been shown.
6.a. Both the tabs are successfully restored, following the crash.
6.b. The promo panel is not shown again for the restored, Reader View-compatible page.

Actual result:
Although browser.reader.detectedFirstArticle is indeed set to true, the promo panel is displayed once again for the restored tab.

Additional notes:
* I've waited about 3 mins before crashing Firefox on Ubuntu 14.04 (x64) and the promo panel was shown again for the restored tab.
* I was unable to reproduce this on Mac OS X 10.9.5.
This is because we're not flushing the prefs via savePrefFile after the change. I supposed we could fix that but hopefully our crash rate is low. If the user hits any other code that causes a flush of the pref file they'll be fine.

We just need to save the pref file via:

on the line after setBoolPref: https://mxr.mozilla.org/mozilla-central/search?string=Services.prefs.setBoolPref%28%22browser.reader.detectedFirstArticle%22&find=ReaderParent&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

and confirm we get the expected result using the STR from comment 0.
Mentor: MattN+bmo
Points: --- → 1
status-firefox38.0.5: --- → affected
status-firefox39: --- → affected
Flags: qe-verify+
Flags: firefox-backlog?
Whiteboard: [lang=js]
(In reply to Matthew N. [:MattN] from comment #1)
> We just need to save the pref file via:

Services.prefs.savePrefFile(null);
Whiteboard: [lang=js] → [lang=js][good first bug]
(Assignee)

Comment 3

2 years ago
Hi, i would like to take this bug
Great! Let me know if you need any help. Comment 1 and Comment 2 has details.
Assignee: nobody → frost17121997
Status: NEW → ASSIGNED
(Assignee)

Comment 5

2 years ago
I'm having difficulty reproducing this bug. I waited for 5 mins after closing the reader mode promo panel,then crashed firefox and after i restarted it, it didn't restore the tabs, and when i navigate to those pages myself, it doesn't show the reader mode promo panel.
If any other code calls savePrefFile before you crash then the problem won't occur. Did you try crashing right after?
(Assignee)

Comment 7

2 years ago
Ok i tried crashing right after closing the reader mode promo,same thing happened again ,the session restore doesn't happen, and when i navigate to the web page, it doesn't show the reader mode promo
Hmm… bug 789945 would have fixed this too but that hasn't be resolved yet.

Let's ask Andrei if he agrees it's WORKSFORME.
Flags: needinfo?(andrei.vaida)
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #8)
> Hmm… bug 789945 would have fixed this too but that hasn't be resolved yet.
> 
> Let's ask Andrei if he agrees it's WORKSFORME.

This is indeed no longer reproducible, at least Fx44+. I think it's safe to mark it wfm.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(andrei.vaida)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.