Closed Bug 682115 Opened 14 years ago Closed 4 years ago

SHistory is *still* broken on Google+

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

STR: * Load http://plus.google.com. This should create two SHEntries. * Click back. Forward button freezes.
Blocks: 670318
This was not fixed by bug 680344, as I'd hoped.
So, the million dollar question is did this reregress or was this never fixed?
Justin, is this reproducible?
(In reply to Ehsan Akhgari [:ehsan] from comment #3) > Justin, is this reproducible? Yes. Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110919 Firefox/9.0a1
Then we need somebody to come up with a regression range here.
Keywords: qawanted, regressionwindow-wanted
Going forward fails because, in nsSHistory::GetCanGoForward, mRequestedIndex == 2, and we can only go forward if mRequestedIndex == -1. I don't know what that means, but Kyle, didn't you mess with this?
I tested with a build from right after bug 670318 was checked in, and it still exhibits this problem, just in a slightly different way. In trunk, when you visit G+, it creates two SHEntries. If you go back to the first one, you can't go forward. GetCanGoForward returns false (*). Right after bug 670318 landed, G+ creates three or more SHEntries (it seems to vary). You can go back and forward between the first two all you want. But once you go back twice, you can no longer go forward. So I'm not sure this ever worked properly. (*) At least, it does the second time it's called. I think we may try and fail halfway doing a navigation, and that's why future requests fail.
Dang. It appears that Google+ pushed an update within the past few hours which fixes the extra SHEntry. There's only one now when you load http://plus.google.com. I got the SHistory stuck one more time, by clicking around the site, but I haven't been able to reproduce since then. :( Jesse, is this the kind of thing you can fuzz for? I think we need some help with this.
I'm confused. Is there some assertion I should look for here? I've got lots of bugs filed on SHEntry-related assertions (bug 645229, bug 656126, bug 622214, bug 623436).
(In reply to Jesse Ruderman from comment #9) > I'm confused. Is there some assertion I should look for here? I've got lots > of bugs filed on SHEntry-related assertions (bug 645229, bug 656126, bug > 622214, bug 623436). I'm pretty sure there wasn't an assertion when this happened. The fuzzer would have to observe that history.back/forward() doesn't work even though it should.
The bug is back this morning; who knows for how long. I'll try to get a handle on it while I can.
I only get the two SHEntries in my release build; in the debug build, I get one. That is supremely unhelpful.
Racy, perhaps? Try a debug build with optimizations?
Build with -O1 is the same as -O0, strangely enough. But I just discovered that, although the back button is disabled, two shentries are displayed when you right-click the back button.
Gah, this site is very nondeterministic; it has a number of different failure modes. Sometimes I get two SHEntries, sometimes I get three. Sometimes the back button is disabled, sometimes it's not. I haven't observed correct behavior from Firefox in any of the various modes. In the case where we click forward but that button does nothing: The first time we click forward, it triggers nsDocShell::LoadURI and sets nsSHistory::mRequestedIndex to the index of the SHEntry we're loading. But the load never completes for some reason, and mRequestedIndex is never set back to -1. So now we have a permanently-pending navigation and the back and forward buttons are disabled.
Need to check, but this should be fixed by Kyle's backout of bug 622315. https://hg.mozilla.org/mozilla-central/rev/60e86b847759
Er, that is not the backout you were looking for. In any case, the plan is for khuey to back out bug 622315 and fix this bug.
And now this is WORKSFORME, since bug 622315 is backed out.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
I guess, at least until we determine that the bug is actually G+ trapping us.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Is bug 725631 a dupe of this bug?
Perhaps, but I can't reproduce bug 725631.

Google+ is no longer active

Status: REOPENED → RESOLVED
Closed: 14 years ago → 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.