1216385 - [e10s] scrolling position lost in about:crashes after click the back button

Status: REOPENED

(Core :: General, defect, P3)

Description

[blinky]

Steps to reproduce:

1. Go to about:crashes.
2. Go to the bottom of the page.
3. Click on one of the crash reports.
4. Click the back button in the browser.


Actual results:

clicking on the Back button leads to Top of the Page about:crashes.

See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/3itqvepb5d.mp4

Comment 1

[blinky]

Also, clicking on one of the crash reports leads to close the developer tools.


Steps to reproduce:

1. Go to about:crashes.
2. Press on ctrl+shift+i.
3. Click on one of the crash reports.

See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/6y5cydpjdx.mp4

Comment 2

[blinky]

Regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1735ff2bb23e&tochange=9e3d649b80a2

Comment 3

[Tracy Walker [:tracy]]

(In reply to blinky from comment #1)
> Also, clicking on one of the crash reports leads to close the developer
> tools.
> 
> 
> Steps to reproduce:
> 
> 1. Go to about:crashes.
> 2. Press on ctrl+shift+i.
> 3. Click on one of the crash reports.
> 
> See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/6y5cydpjdx.mp4

^^^ that should be filed as a separate bug.

Comment 4

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Hi guys,

This issue is still reproducible on latest Aurora (46.0a2-20160208004010) and latest Nightly (47.0a1-20160208030244) with e10s, but not on the Firefox 44.0 release. The view is reset to top when returning from crash report page.

However, I have seen also a strange behavior on Aurora and Nightly builds, and I don't know if this is intended or not. When opening an old archived crash that needs to be fetched before displayed (2011-2015 crashes). The opened "report ID" is moved on top of the list and the "submitted date" is changed with the current one like it has been resubmitted. The same as above, this behavior only occurs on Aurora and Nightly, but not on 44.0 release.
I have used the same crash reports list since it's shared with all Firefox installed versions on my PC.

Performed a couple of searches trough Bugzilla but couldn't find anything related. Jim, is this an issue or it's the intended behavior ?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Paul Oiegas [:pauloiegas] from comment #4)
> Hi guys,
> 
> This issue is still reproducible on latest Aurora (46.0a2-20160208004010)
> and latest Nightly (47.0a1-20160208030244) with e10s, but not on the Firefox
> 44.0 release. The view is reset to top when returning from crash report page.
> 
> However, I have seen also a strange behavior on Aurora and Nightly builds,
> and I don't know if this is intended or not. When opening an old archived
> crash that needs to be fetched before displayed (2011-2015 crashes). The
> opened "report ID" is moved on top of the list and the "submitted date" is
> changed with the current one like it has been resubmitted. The same as
> above, this behavior only occurs on Aurora and Nightly, but not on 44.0
> release.
> I have used the same crash reports list since it's shared with all Firefox
> installed versions on my PC.

Sounds like a crash report page bug. Lets get it on file with str.

Comment 6

[blinky]

(In reply to Tracy Walker [:tracy] from comment #3)
> (In reply to blinky from comment #1)
> > Also, clicking on one of the crash reports leads to close the developer
> > tools.
> > 
> > 
> > Steps to reproduce:
> > 
> > 1. Go to about:crashes.
> > 2. Press on ctrl+shift+i.
> > 3. Click on one of the crash reports.
> > 
> > See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/6y5cydpjdx.mp4
> 
> ^^^ that should be filed as a separate bug.

This bug already exists in bug 1068400.

Comment 7

[blinky]

I can also reproduce in about:support page.

See https://dl.dropboxusercontent.com/u/95157096/85f61cf7/8r280hsomk.mp4

Comment 8

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

(In reply to Jim Mathies [:jimm] from comment #5)
> (In reply to Paul Oiegas [:pauloiegas] from comment #4)
> > Hi guys,
> > 
> > This issue is still reproducible on latest Aurora (46.0a2-20160208004010)
> > and latest Nightly (47.0a1-20160208030244) with e10s, but not on the Firefox
> > 44.0 release. The view is reset to top when returning from crash report page.
> > 
> > However, I have seen also a strange behavior on Aurora and Nightly builds,
> > and I don't know if this is intended or not. When opening an old archived
> > crash that needs to be fetched before displayed (2011-2015 crashes). The
> > opened "report ID" is moved on top of the list and the "submitted date" is
> > changed with the current one like it has been resubmitted. The same as
> > above, this behavior only occurs on Aurora and Nightly, but not on 44.0
> > release.
> > I have used the same crash reports list since it's shared with all Firefox
> > installed versions on my PC.
> 
> Sounds like a crash report page bug. Lets get it on file with str.

I finally made some time to dig into this and in the end I realized it's not an issue. 
After I performed a manual regression and found that the mentioned behavior was caused by bug 378528 from 2009, I had an idea to add my crash reports folder as testing dataset for the new bug. There I found that the crashes are split in two, pending and submitted. When I compared the submitted list reports by accessing the same ones from "about:crashes" page, this behavior didn't occurred anymore. So, this only happens for the reports from the page that have pending state and this is the normal behavior. 

However, the strange thing after this is that the list of pending ones is significantly larger than the submitted one (53 vs 372), and I always chose to submit my crash reports. But this could be a whole other issue.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

WFM based on comment 8

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

reopening, comment 8 was not about the originally reported bug.

This looks to be only occur when navigating between chrome and content pages

Comment 11

[Tracy Walker [:tracy]]

Yes, as originally reported, this bug is still reproducible.  Also checked on about:support, and scroll position is lost on Back/Forward.

Comment 12

[atlanto]

abandoned issue.
missing entry.scroll settlement. (remained undefined)
losing tabState.scroll update. (unmatched index)
who cares SessionStore.jsm/navigateAndRestore or others.
54.0a1 is under going.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information