Closed Bug 1352447 Opened 3 years ago Closed 2 years ago

loading tabs fails without getting any error (probably connection is lost somewhere in the middle of loading headers) the tab gets converted into blank new-tab &no content & data lost.

Categories

(Firefox :: Session Restore, defect)

52 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 610357

People

(Reporter: u589863, Unassigned)

References

()

Details

(Keywords: dataloss, regressionwindow-wanted)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.111 Safari/537.36 Vivaldi/1.8.770.46

Steps to reproduce:

try with e10s on/off(off has a better chance) & on a slow or not good connection
Starting with firefox 52

open multiple tabs quickly say 10 + on a flaky connection, tabs starts loading but sometimes loading stops and instead of showing error page it converts into blank tab with no url or any data

or on a page with many images quickly open 15-20 images as again instead of error due to network problem the tabs gets converted to new blank tabs


Actual results:

This is causing data loss (URL) in some cases, especially on slow ISPs and when closing not fully loaded website pages.It looks critical as data loss is happening especially on slow 2g/3g or latency problems.
Reddit images or sites sometimes keep loading then convert to new-tab on weak 2g/3g connections instead of showing problem loading pages, and site info is lost.
it keep loading then convert to new-tab especially with tab heavy browsing.
problem hits especially when suddenly while loading(progress to load  on tab starts) but they turn into new tab ie ALL DATA lost


Expected results:

If the connection timed out or there was a network error like in Firefox 51 it should throw error and the tab data is stored and the tab can be reloaded.
The user data should not be lost.


PS: sorry if wrong bug- guide to right one is appreciated
Severity: normal → critical
Component: Untriaged → Session Restore
Flags: needinfo?(nfroyd)
Flags: needinfo?(mlongaray)
Flags: needinfo?(mdeboer)
Flags: needinfo?(hani.yacoub)
OS: Unspecified → All
Priority: -- → P1
Hardware: Unspecified → All
[Tracking Requested - why for this release]:
Has Regression Range: --- → yes
Has STR: --- → yes
visit this page

https://www.reddit.com/r/aww/top/?feature=new_theme

and on a slow/error prone connection open many images quickly in new tabs 

many of them load and many image contains tabs get blank


just now this one went blank, reopened from the page again and it then loaded fine

https://i.reddituploads.com/84cd9e2c2f3b413da4a646736544c112?fit=max&h=1536&w=1536&s=40844ff9c6767cc733ca1b63b8e90a65
Hi Sunil. I appreciate that your attempt at making us aware of an issue that you think is very important to fix as soon as possible.

What I don't appreciate is the flurry of flags you set (including needinfo's) and make it block many issues and assume a certain priority (P1/ critical). All this does _not_ help in getting people to look at this sooner, because the positive activation strategies have been side-stepped entirely.
You're just flooding inboxes with notification mails.

Please re-read and try to adhere to the Bugzilla Etiquette (linked below the comment form).

I will keep the needinfo request for myself to take a look at this somewhere early next week.
No longer blocks: ss-perf, ss-feature
Severity: critical → normal
Flags: needinfo?(nfroyd)
Flags: needinfo?(mlongaray)
Flags: needinfo?(hani.yacoub)
Priority: P1 → --
(In reply to Mike de Boer [:mikedeboer] from comment #3)
> Hi Sunil. I appreciate that your attempt at making us aware of an issue that
> you think is very important to fix as soon as possible.
> 
> What I don't appreciate is the flurry of flags you set (including
> needinfo's) and make it block many issues and assume a certain priority (P1/
> critical). All this does _not_ help in getting people to look at this
> sooner, because the positive activation strategies have been side-stepped
> entirely.
> You're just flooding inboxes with notification mails.
> 
> Please re-read and try to adhere to the Bugzilla Etiquette (linked below the
> comment form).
> 
> I will keep the needinfo request for myself to take a look at this somewhere
> early next week.

sorry for that , wasn't the form supposed to be filled to help properly?
what exactly should only be filled? affects all since FF52 so filled the form.

Sorry once again only trying to be a help
Hi Sunil - thanks for helping us out - that's the most important thing and I can not appreciate that enough! :)

To clarify: the flags you set and used are basically used for tracking and pinging people who might be able to help you resolve the issue. The explanation for setting these flags would preferably be in the bug description field or a comment, so that we all know what's going on.

A question: what's going on with your user agent string? That can't be the Firefox default. What happens when you set it back to normal?

Mike, since this is happening _since_ 52, does it feel familiar to you?
Flags: needinfo?(mdeboer) → needinfo?(mconley)
Version: 55 Branch → 52 Branch
This bug looks like duplicate issue of bug #610357.

@ Sunil Kumar - Is it reproducible also in Firefox 51?
Has Regression Range: yes → no
I can reproduce this using Network Link Conditioner on OS X, and setting it to 100% packet loss, and then loading a link from some page.

This feels like a lower-level issue, and I'm not having much luck tracking it down. I _suspect_ it's happening somewhere in the interaction between nsDoc* stuff and Necko though. I'm going to ni? jduell to see if he knows anybody who might have some time to look at this.
Flags: needinfo?(mconley) → needinfo?(jduell.mcbugs)
This smells mostly like an upper-layer bug: even if necko is falling down, it will almost definitely be notifying the listener with an error code:  if we should be handling that error more gracefully in terms of what we show the user, that's not our wheelhouse. (Sadly that includes nsDoc* stuff--not a lot of in-house necko team knowledge)

That said, the fact that channels appear to be failing a lot during session restore on a slow network is interesting.  If the network is crappy enough and there are enough channels getting loaded, perhaps we're timing out in some way we could avoid?  So there might be a necko bug to split out here.  I'll leave it to Patrick to determine if that's the case.

I'm on PTO till May 3rd so don't take it personally if I don't reply in this bug for a while... :)
Flags: needinfo?(jduell.mcbugs) → needinfo?(mcmanus)
can someone retest on the latest nightly? I cannot put my finger on the bug, but very recently (certainly in 55) we changed an error code (in some circumstances) which docshell uses to write the error page. It might apply here.
Flags: needinfo?(mcmanus)
I'm hitting this today on the latest nightly. It seems to end up with the blank tab if it fails early while loading, because I'm getting what seems to be a 50/50 mix of blank tabs and error pages.
No reply from the OP for long time to comment #6, so I'm closing this bug, as duplicate of bug #610357.
No longer blocks: ss-reliability
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 610357
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #6)
> This bug looks like duplicate issue of bug #610357.
> 
> @ Sunil Kumar - Is it reproducible also in Firefox 51?

hi there not op but it's not reproducible in v51

So might be different not duplicate
Flags: needinfo?(Virtual)
But if you can't reproduce it in Firefox 51 and can in Firefox 52, finding regression range with mozregression ( http://mozilla.github.io/mozregression/ ) will help
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #14)
> But if you can't reproduce it in Firefox 51 and can in Firefox 52, finding
> regression range with mozregression (
> http://mozilla.github.io/mozregression/ ) will help

Just used it to find a bug from sept last year with mozregression, don't have permissions to see it.
That fix broke between v51 & v52.
anything else i can help
You need to log in before you can comment on or make changes to this bug.