u589863 Reporter
	Description • 7 years ago

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

	u589863 Reporter
	Comment 1 • 7 years ago

[Tracking Requested - why for this release]:

	u589863 Reporter
	Comment 2 • 7 years ago

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

	Mike de Boer [:mikedeboer]
	Comment 3 • 7 years ago

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.

	u589863 Reporter
	Comment 4 • 7 years ago

(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

	Mike de Boer [:mikedeboer]
	Comment 5 • 7 years ago

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?

	Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
	Comment 6 • 7 years ago

This bug looks like duplicate issue of bug #610357.

@ Sunil Kumar - Is it reproducible also in Firefox 51?

	Mike Conley (:mconley) (:⚙️)
	Comment 7 • 7 years ago

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.

	Jason Duell
	Comment 8 • 7 years ago

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... :)

	Patrick McManus [:mcmanus]
	Comment 9 • 7 years ago

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.

	Alex
	Comment 10 • 7 years ago

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.

	Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
	Comment 11 • 7 years ago

No reply from the OP for long time to comment #6, so I'm closing this bug, as duplicate of bug #610357.

	u595641
	Comment 12 • 7 years ago

(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

	Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
	Comment 13 • 7 years ago

I will wait for OP reply.

	Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
	Comment 14 • 7 years ago

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

	u595641
	Comment 15 • 7 years ago

(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