When using Fennec Beta 14 I sometimes get into a scenario where when I click back the page content does not change. It remains at the page I was on before I click back. If I click reload the page does reload as expected. For example, when browsing on craigslist, if I click on an entry to view it and then click back to return to the listing page, I am still shown the entry page. Clicking reload then loads the listing page again. Unfortunately I cannot reliably reproduce this issue and it happens infrequently. I will try to get a log the next time it occurs.

Hi Lawrence, thanks for the report. I take it this is with the latest beta 14. May I ask which device were you on? Also feel free to grab us from QA when you do see it occurring. A logcat would be wonderful! :)

Yes. Latest Fennec Beta 14. Device is Samsung Galaxy S2. I will try to grab a logcat and, if I can reproduce while at the office, will grab aaronmt or someone from the gfx team.

What happens if you pan or zoom after you push back? (I.e., is this caused by not redrawing?)

qawanted for STR

(In reply to Joe Drew (:JOEDREW!) from comment #3) > What happens if you pan or zoom after you push back? (I.e., is this caused > by not redrawing?) Tried both panning and zooming. Neither caused the correct page to be redrawn. I don't know if the elements in the page were active. (I didn't try clicking on any links.)

What happens if you opens and close the address bar?

(In reply to microrffr from comment #6) > What happens if you opens and close the address bar? Do you mean by touching in the address bar to open my awesomebar listing? If so, I didn't try this.

Tried a bunch of sites including Craigslist with Beta over the Galaxy Nexus and Droid Pro and could not reproduce. Should this continue to block if its reported as intermittent behaviour and without concrete STR?

As the submitter, I don't think it's worth blocking on this. I haven't been able to reproduce the issue since I filed the bug. Worst case the browser occasionally gets into this state and needs to be restarted.

Un-setting blocking based on comment 8 and 9. Please re-nominate if steps to reproduce or other data are found.

What happens when you tap the Android back button multiple times?

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #11) > What happens when you tap the Android back button multiple times? Clicking back twice loads the page that is two back in my history as expected. A concrete example, if on Craigslist and viewing an item page, clicking back twice returns me to the main Craigslist category listing page (where all categories are shown).

I was able to reproduce this issue again and have captured a logcat - attached is the relevant portion.

Here's a video showing the problem. In the video I: 1. click on a link in Craigslist to display an item listing page. 2. click the physical back button. The page title changes but the content stays the same. 3. click the Reload menu item to reload the page. The correct content is now loaded. http://youtu.be/AhF4nY3afd0

I could not reproduce this issue, but I noticed on b7b1 that on reload, the page sometimes turns completely blank: http://toronto.en.craigslist.ca/tor/zip/3076746698.html (after zooming out and being scrolled to the bottome, then reload) With b7b2, I couldn't reproduce this, I think because of the fixes for bug 759678, bug 763592 might have fixed this. In any case, I suspect the b7b2 build might not show this issue, could you try out that build perhaps?

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #15) > I could not reproduce this issue, but I noticed on b7b1 that on reload, the > page sometimes turns completely blank: > http://toronto.en.craigslist.ca/tor/zip/3076746698.html > (after zooming out and being scrolled to the bottome, then reload) > > With b7b2, I couldn't reproduce this, I think because of the fixes for bug > 759678, bug 763592 might have fixed this. Yeah, this was likely fixed by bug 763592. > > In any case, I suspect the b7b2 build might not show this issue, could you > try out that build perhaps? I could be wrong, but I don't think it would fix the issue Lawrence is describing. Bug 763592 specifically affects reload behaviour, and the issue he was having seems more to do with the "back" function not working properly. I looked through the logcat and on the "back" the DOMContentLoaded message seems to be missing, which is kind of odd. I don't think that should cause this behaviour but it's suspicious and warrants further investigation.

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #15) > In any case, I suspect the b7b2 build might not show this issue, could you > try out that build perhaps? I will try again with the new build. Unfortunately, as I said in comment 0, I can't reliably reproduce this issue. I had been trying to reproduce the issue since filing and it happened to occur last night - at which point I grabbed the log and took the video to capture what I could.

Just fyi, I get the impression that after the "back" button, the page is loaded from bfcache, since it's there instantly. And because the page has meta user-scalable tags, I presumed it might have been fixed by bug 763592.

(In reply to Kartikaya Gupta (:kats) from comment #16) > I could be wrong, but I don't think it would fix the issue Lawrence is > describing. Bug 763592 specifically affects reload behaviour, and the issue > he was having seems more to do with the "back" function not working > properly. I looked through the logcat and on the "back" the DOMContentLoaded > message seems to be missing, which is kind of odd. I don't think that should > cause this behaviour but it's suspicious and warrants further investigation. I don't think DOMContentLoaded is generally fired again when navigating back/forward with the bfcache; it might be better to use pageshow in these cases. This isn't very well-documented; [1] is the closest I could find, but it doesn't explicitly mention DOMContentLoaded. But this behavior is described in blogs [2], and I've seen the same thing when investigating bugs that rely on these events. [1] https://developer.mozilla.org/En/Using_Firefox_1.5_caching#pageshow_event [2] http://mike.kaply.com/2007/11/19/operator-and-page-load-performance/

Yeah, looking through the code, the only thing that really happens on DOMContentLoaded is the setting of the background colour. That's a bug that should be fixed but is unrelated to this problem.

Removing qawanted since STR and video of the result have been added to the bug. Please readd if more information is needed.

Ideally, we want to have some way of reproducing this 100% of the time, not sporadically.

(In reply to Lawrence Mandel [:lmandel] from comment #17) > (In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #15) > > In any case, I suspect the b7b2 build might not show this issue, could you > > try out that build perhaps? > > I will try again with the new build. Unfortunately, as I said in comment 0, > I can't reliably reproduce this issue. I had been trying to reproduce the > issue since filing and it happened to occur last night - at which point I > grabbed the log and took the video to capture what I could. I can still reproduce this issue with the latest beta. I experienced this issue while browsing on Amazon yesterday (June 17).

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.