Closed Bug 1354796 Opened 7 years ago Closed 7 years ago

Right-click new tab loses URL information if site is down

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla55
Tracking Flags:
Tracking Status
firefox52 --- wontfix
firefox-esr52 55+ verified
firefox53 - wontfix
firefox54 + verified
firefox55 + verified

People

(Reporter: berend.de.schouwer, Assigned: mayhemer)

References

Details

(Keywords: dataloss, regression, Whiteboard: [necko-active])

Attachments

(1 file, 1 obsolete file)

v1 (NS_ERROR_ABORT -> NS_ERROR_NET_TIMEOUT)
1.71 KB, patch
mcmanus
: review+
gchang
: approval-mozilla-beta+
ritu
: approval-mozilla-esr52+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170327113357

Steps to reproduce:

1. go to any site with a a href
   a. the link must currently be down
2. right-click -> open in new tab


Actual results:

3. site opens in new tab with "https://somesite.com/" in the URL bar
4. 90 second timeout
5. URL bar reverts to "about:blank"


Expected results:

5. URL bar stays on "https://somesite.com" so that the user can refresh.
This is a regression.  Firefox 52 has the problem.  Firefox 51 keeps the URL bar with the relevant information.
This was opened as not-a-duplicate of #610537 at the request of Dão Gottwald
To test it, you can make a simple html page on localhost with:

<html>
<head>
<body>
<a href="https://example.com/">example.com</a>
</body>
</html>

To make testing easier example.com should be on a static IP, ie. not on a CDN or reverse proxy.


To test it, make a firewall rule so the SYN ACK never comes back.
A note on testing:

The cache should be empty.  If example.com is in the cache, you'll retrieve that, and the URL bar will not revert back to about:blank.
(In reply to Berend De Schouwer from comment #2)
> This was opened as not-a-duplicate of #610537 at the request of Dão Gottwald

610357

apologies
If you have the setup to reproduce this reliably, can you find a narrower regression window? https://mozilla.github.io/mozregression/ can help with this.
Flags: needinfo?(berend.de.schouwer)
Keywords: dataloss, regression, regressionwindow-wanted
Component: Untriaged → Location Bar
So what would be the nightly dates for 52 and 51?
(In reply to Berend De Schouwer from comment #7)
> So what would be the nightly dates for 52 and 51?

This is a good page to look for those:

https://wiki.mozilla.org/RapidRelease/Calendar
(In reply to Mark Banner (:standard8) from comment #8)
> (In reply to Berend De Schouwer from comment #7)
> > So what would be the nightly dates for 52 and 51?
> 
> This is a good page to look for those:
> 
> https://wiki.mozilla.org/RapidRelease/Calendar

FWIW, it's possible that the change happened later than the branching date where 52 went to aurora, because sometimes things get uplifted after the nightly date.

It would probably make sense to just run mozregression with --good 51 (and, implied, today's nightly is bad).
Relevant info from mozregression:

132:42.35 INFO: Got as far as we can go bisecting nightlies...
132:42.35 INFO: Last good revision: 66a77b9bfe5dcacd50eccf85de7c0e7e15ce0ffd (2016-09-28)
132:42.35 INFO: First bad revision: f7d5008ee2ab9200052e45ad6ecc3f3a348f7f86 (2016-09-29)

139:41.48 INFO: Oh noes, no (more) inbound revisions :(
139:41.48 INFO: Last good revision: 1e7f590415adb88c3699ff073111027e1edf1592
139:41.48 INFO: First bad revision: b1d60f2f68c7cccc96fcf9a2075bb430a500a0f2

219:00.04 INFO: Oh noes, no (more) inbound revisions :(
219:00.04 INFO: Last good revision: cde7a9badcab194e25adf5fc48a991f6fa41fb87
219:00.04 INFO: First bad revision: a45cfe898352daa445ebc702273c73c56b3ef3a1

219:09.04 INFO: Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1284395


#1284395 is private.
Flags: needinfo?(berend.de.schouwer)
Blocks: CVE-2017-5420
Status: UNCONFIRMED → NEW
status-firefox52: --- → wontfix
status-firefox53: --- → wontfix
status-firefox54: --- → affected
status-firefox55: --- → affected
Ever confirmed: true
Keywords: regressionwindow-wanted
why will this not be fixed in esr52?
It's a long term release.
(In reply to Berend De Schouwer from comment #10)
> Relevant info from mozregression:
> 
> 132:42.35 INFO: Got as far as we can go bisecting nightlies...
> 132:42.35 INFO: Last good revision: 66a77b9bfe5dcacd50eccf85de7c0e7e15ce0ffd
> (2016-09-28)
> 132:42.35 INFO: First bad revision: f7d5008ee2ab9200052e45ad6ecc3f3a348f7f86
> (2016-09-29)
> 
> 139:41.48 INFO: Oh noes, no (more) inbound revisions :(
> 139:41.48 INFO: Last good revision: 1e7f590415adb88c3699ff073111027e1edf1592
> 139:41.48 INFO: First bad revision: b1d60f2f68c7cccc96fcf9a2075bb430a500a0f2
> 
> 219:00.04 INFO: Oh noes, no (more) inbound revisions :(
> 219:00.04 INFO: Last good revision: cde7a9badcab194e25adf5fc48a991f6fa41fb87
> 219:00.04 INFO: First bad revision: a45cfe898352daa445ebc702273c73c56b3ef3a1
> 
> 219:09.04 INFO: Looks like the following bug has the  changes which
> introduced the regression:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1284395
> 
> 
> #1284395 is private.

wow thank you , you found the problem.
Uplift to esr52 maybe , is a longterm release.
Flags: needinfo?(mdeboer)
Flags: needinfo?(mconley)
(In reply to Sunil Kumar from comment #11)
> why will this not be fixed in esr52?
> It's a long term release.

No flag has been set for esr52, only for the "regular" (not esr) 52 release, which is almost EOL given we're releasing 53 next week (which is therefore also wontfix).

Please don't set needinfo flags for others on bugs without making it clear why you're doing so or what you expect those people to help you with.



The regressing bug here was a security fix. While it might be possible to adjust it so it doesn't impact usage like in this bug, it won't be trivial to do so.
Flags: needinfo?(mdeboer)
Flags: needinfo?(mconley)
[Tracking Requested - why for this release]: Recent UX / dataloss regression affecting primary UI

https://hg.mozilla.org/mozilla-central/rev/a45cfe898352daa445ebc702273c73c56b3ef3a1 is Gijs' baby
tracking-firefox54: --- → ?
tracking-firefox55: --- → ?
Flags: needinfo?(gijskruitbosch+bugs)
I can't actually reproduce the problem here... when I e.g. create a link to localhost, open it in a new tab, and make sure my http server is turned off, I get an error page with "Firefox can’t establish a connection to the server at 127.0.0.1.". This happens irrespective of whether the OS firewall is turned on. I'm testing on OS X.

What's different in your setup?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(berend.de.schouwer)
You need a TCP timeout.

If you stop your HTTP server, you'll get a TCP RST from the OS, and you'll get it quickly.

If you drop the TCP SYN or SYN ACK packet you'll get a socket connect timeout after 90 seconds.
Flags: needinfo?(berend.de.schouwer)
Most firewalls default to TCP RST, and don't drop the response.

Most firewalls automatically exclude the loopback interface, so you need to write manual firewall rules or don't test on localhost.
(In reply to Berend De Schouwer from comment #17)
> Most firewalls default to TCP RST, and don't drop the response.

According to the docs at https://www.openbsd.org/faq/pf/options.html#block-policy, pf (which is what ships with osx) defaults to 'drop'. Even if I manually add set block-policy drop, the result doesn't change, nor if I manually add a rule to block drop all tcp/udp packets on a given port, and try to access it on that port.


> Most firewalls automatically exclude the loopback interface, so you need to
> write manual firewall rules or don't test on localhost.

I tested reaching my mbp from another machine, on a port without the http server, with the firewall running, it produces the same result ("Unable to connect, Firefox can't establish a connection to the server at ..., etc. etc.").

I checked with wireshark on the mbp, I see no packets leaving the mbp addressed to the machine doing the accessing (only incoming packets).

Still getting normal error messages.
Flags: needinfo?(berend.de.schouwer)
I get a normal message(s) at the bottom, but I also get the location bar changing back to "about:blank" instead of retaining the URL.

Do you get a 90 second wait?

Linux, iptables.
(In reply to Berend De Schouwer from comment #19)
> I get a normal message(s) at the bottom,

Sorry, you mean you do see a normal error page (see below) ? Or are you talking about the status-bar-like popups saying "Connecting to <whatever>...", or something else still?

> but I also get the location bar
> changing back to "about:blank" instead of retaining the URL.

No, the location bar stays the same and I get a normal error page (similar to e.g. cert errors or what happens if you put a domain for which dns lookup fails, but with different messages on it of course). The title of the tab changes to "Problem loading page", with a warning triangle icon.

> Do you get a 90 second wait?

I do see a wait, but it seems to be about 20 seconds (checked with a stopwatch). Are you reproducing with a clean Firefox profile?

What specific rules are you using with iptables?
AFAIK it's a clean firefox profile.  I did it with a newly created user, and mozregression.

I get a blank page with either a "good" or "bad" firefox after 90 seconds, and the normal status messages "lookup up... ; connecting to ... "  I also see "connecting to" in the tab title.

I don't get an error page.  The page is blank.  This is a normal experience for me.

For me it's very close to 90 seconds.  Is a TCP socket timeout different per OS?  20 seconds seems awfully short.  I have a number of networks in Africa that need a longer timeout than that, or they'll never ever work, mostly over satellite.

iptables --protocol tcp --destination 1.2.3.4/32 --jump DROP
Flags: needinfo?(berend.de.schouwer)
I've done the tests again after rm -rf .mozilla and confirmed that I got the first run page, and that about:addons is empty.
I do get an error page on DNS failures, but not on socket timeouts.

(I'm typing so much I'd like to use IRC...)
(In reply to Berend De Schouwer from comment #23)
> I do get an error page on DNS failures, but not on socket timeouts.
> 
> (I'm typing so much I'd like to use IRC...)

IRC would be great. We're on irc.mozilla.org/#developers . :-)

Yeah, so, apparently the difference in timeout is that on Windows 21 seconds is expected. On OS X I see 75 seconds, but I still get an error page and the location bar stays the same (no about:blank ).

The real issue here, IMO, is that you should be getting an error page. I can come up with mitigations for the changes in bug 1284395 for this usecase (and try not to regress the security issue...) but you'd still get a white page which is IMO a suboptimal UX.

I'll try to repro on Linux, but if we're somehow using OS limits on socket timeout, is there a chance you changed something on a lower level than Firefox?

I asked someone else for help, they'll probably ask you for a log in a few minutes. :-)
So, thanks ThreeFourSeven for logs and info provided on IRC!  I believe I've identified the source of the blank page problem.  On linux, under some circumstances (a server/firewall simply dropping any TCP packets to a port) the connection timeout goes over 90 secs.  We have a code that handles that specifically at

https://dxr.mozilla.org/mozilla-central/rev/b1364675bdf5dffe63fd60373034293de0b513d5/netwerk/protocol/http/nsHttpConnectionMgr.cpp#2780

We close sockets with NS_ERROR_ABORT which probably gets propagated up to docshell which doesn't show any error page for that error.

We should close the socket with NS_ERROR_NET_TIMEOUT instead?
Flags: needinfo?(mcmanus)
you suggestion makes sense to me. double check with dragana as she has been working with the HalfOpen stuff the most recently - probably the right reviewer.
Flags: needinfo?(mcmanus) → needinfo?(dd.mozilla)
thanks for digging in, providing logs, etc.. everyone.
Bug 1284395 definitely exposed this, but the core fix here is unrelated, so I'm moving it to 'see also'.
No longer blocks: CVE-2017-5420
Component: Location Bar → Networking
Product: Firefox → Core
See Also: → CVE-2017-5420
(In reply to :Gijs from comment #13)
 
> No flag has been set for esr52, only for the "regular" (not esr) 52 release,

So that was a hindsight as esr 52 will be supported for long and this nasty but is present and reproducible there.

> The regressing bug here was a security fix. While it might be possible to
> adjust it so it doesn't impact usage like in this bug, it won't be trivial
> to do so.

Not even for esr? and when Fx57 is going to make some huge changes?
(In reply to Sunil Kumar from comment #29)
> (In reply to :Gijs from comment #13)
>  
> > No flag has been set for esr52, only for the "regular" (not esr) 52 release,
> 
> So that was a hindsight as esr 52 will be supported for long and this nasty
> but is present and reproducible there.

IME we don't normally make decisions for esr until we have a patch for a bug in the first place, so we can judge how hard it is to backport, except for critical security issues that we already know from the point of bug-filing will need to be backported to keep users safe. So no, not an oversight.

> > The regressing bug here was a security fix. While it might be possible to
> > adjust it so it doesn't impact usage like in this bug, it won't be trivial
> > to do so.
> 
> Not even for esr? and when Fx57 is going to make some huge changes?

That's really not what I said, I simply said this bug was not trivial to fix by means of somehow updating or backing out the fix from 1284395.

It looks like we will create a different kind of fix to what I thought initially, given the fundamental issue is elsewhere. Whether that gets put into ESR 52 is up to the networking team, but now is definitely too early to tell. So, please stop speculating about ESR and wait for this to at least be fixed on trunk (nightly) before raising the matter again.
status-firefox-esr52: --- → affected
(In reply to :Gijs from comment #30)
> (In reply to Sunil Kumar from comment #29)
> > (In reply to :Gijs from comment #13)
> >  
> > > No flag has been set for esr52, only for the "regular" (not esr) 52 release,
> > 
> > So that was a hindsight as esr 52 will be supported for long and this nasty
> > but is present and reproducible there.
> 
> IME we don't normally make decisions for esr until we have a patch for a bug
> in the first place, so we can judge how hard it is to backport, except for
> critical security issues that we already know from the point of bug-filing
> will need to be backported to keep users safe. So no, not an oversight.
> 
> > > The regressing bug here was a security fix. While it might be possible to
> > > adjust it so it doesn't impact usage like in this bug, it won't be trivial
> > > to do so.
> > 
> > Not even for esr? and when Fx57 is going to make some huge changes?
> 
> That's really not what I said, I simply said this bug was not trivial to fix
> by means of somehow updating or backing out the fix from 1284395.
> 
> It looks like we will create a different kind of fix to what I thought
> initially, given the fundamental issue is elsewhere. Whether that gets put
> into ESR 52 is up to the networking team, but now is definitely too early to
> tell. So, please stop speculating about ESR and wait for this to at least be
> fixed on trunk (nightly) before raising the matter again.

Oh sorry i misunderstood, thanks for explaining .
One more thing will this also solve bug 610357 or it's totally different?
Whiteboard: [necko-next]
I can reproduce this often even when a site is not down but my network conditions are not good (e.g. if there's another program heavily using the network).
(In reply to Marco Castelluccio [:marco] from comment #33)
> I can reproduce this often even when a site is not down but my network
> conditions are not good (e.g. if there's another program heavily using the
> network).

yes can reproduce this too easily.

Will this be fixed as it's getting worse and loosing critical data & Bug 610357 too,
any one with more than 10 tabs can hit this repeatedly 
Or would users have to switch to other browsers since the devs do not seem to care about this?
Flags: needinfo?(mcmanus)
Flags: needinfo?(dao+bmo)
Flags: needinfo?(berend.de.schouwer)
(In reply to Patrick McManus [:mcmanus] from comment #26)
> you suggestion makes sense to me. double check with dragana as she has been
> working with the HalfOpen stuff the most recently - probably the right
> reviewer.

This make sense.

The solution from comment 25, may not fix bug 610357, depend when and how the channel is canceled.
Flags: needinfo?(dd.mozilla)
honza, seems like you almost have a patch from comment 25.. do you want to take this on for landing or maybe ask if junior or gary can finish it?
Flags: needinfo?(mcmanus) → needinfo?(honzab.moz)
I can create the patch and ask for testing it.
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Flags: needinfo?(honzab.moz)
Whiteboard: [necko-next] → [necko-active]
locally tested with a connection to a local address where nothing is listening and the timeout lowered to 3 secs only.  No test added for this, I leave that to someone else.
Flags: needinfo?(dao+bmo)
Flags: needinfo?(berend.de.schouwer)
Attachment #8864182 - Flags: review?(mcmanus)
Attachment #8864182 - Flags: review?(mcmanus) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fbad88a61127
Close unconnected HTTP connection with NS_ERROR_NET_TIMEOUT after 90s timeout. r=mcmanus
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/fbad88a61127
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Should we consider this for uplift or can it ride the 55 train?
Flags: needinfo?(honzab.moz)
This is safe to uplift IMO.  But as it's not a regression I would rather let it ride.  But these days, what the hell is a difference?
Flags: needinfo?(honzab.moz)
From comment 1, it looks like this is a regression, even though not a recent one.
Here's a link you can use to recreate this consistently:

https://ssltest39.ssl.symclab.com:4/

On mobile, this manifests worse than desktop because even just loading the URL via Paste & Go or just Paste and clicking Go aborts with no message at all (so you don't know what happened).

Since this is a regression (even an older one), I'd like to see this uplifted. It was also discovered by one of our partners running tests on mobile.
(In reply to Marco Castelluccio [:marco] from comment #43)
> From comment 1, it looks like this is a regression, even though not a recent
> one.

I missed that.  OK, let's uplift.  Still, I would like to know why this has regressed in 52...
Patrick, looking into the history, it seems we used to have NET_TIMEOUT here, but you've changed to ABORT in https://bugzilla.mozilla.org/attachment.cgi?id=770390&action=diff

What do you think?
Flags: needinfo?(mcmanus)
(In reply to Honza Bambas (:mayhemer) from comment #46)
> (In reply to Marco Castelluccio [:marco] from comment #43)
> > From comment 1, it looks like this is a regression, even though not a recent
> > one.
> 
> I missed that.  OK, let's uplift.  Still, I would like to know why this has
> regressed in 52...

why will this not be fixed in esr52?
It's a long term release.
Please uplift for ESR52 as it where it first regressed and it's a longterm release.
plus will this fix bug 610357 ?
both were regressed in 52...
Flags: needinfo?(honzab.moz)
good detective work honza - the checked in fix will bring back bug 878792 because, as that bug explains, timeout initiates a retry on the socket an now there is no listener on the socket. That bug doesn't impact too many people, but it has a really bad impact when it does.

NOTE for RELMAN - Don't uplift from 55 until that's fixed. and indeed this is intricate enough that the risk of uplift might be too high all together.

I think a possible solution might be to leave the code at TIMEOUT (as the 55 patch has done) - which ought to make the empty tab fix work - but to add a SocketTransport()->Close(NS_ERROR_ABORT) (and backuptransport variant) into the Abandon() method before the AsyncWait(null).. That should probably fix the original 878792 issue. I'm curious what dragana thinks.
Flags: needinfo?(mcmanus) → needinfo?(dd.mozilla)
(In reply to Mefoster from comment #48)
> why will this not be fixed in esr52?

Will be, but see comment 50 first.
Flags: needinfo?(honzab.moz)
Since this issue has been there for a while and the patch may bring back bug 878792. Mark 54 fix-optional.
status-firefox54: affected → fix-optional
(In reply to Patrick McManus [:mcmanus] from comment #50)
> good detective work honza - the checked in fix will bring back bug 878792
> because, as that bug explains, timeout initiates a retry on the socket an
> now there is no listener on the socket. That bug doesn't impact too many
> people, but it has a really bad impact when it does.
> 
> NOTE for RELMAN - Don't uplift from 55 until that's fixed. and indeed this
> is intricate enough that the risk of uplift might be too high all together.
> 
> I think a possible solution might be to leave the code at TIMEOUT (as the 55
> patch has done) - which ought to make the empty tab fix work - but to add a
> SocketTransport()->Close(NS_ERROR_ABORT) (and backuptransport variant) into
> the Abandon() method before the AsyncWait(null).. That should probably fix
> the original 878792 issue. I'm curious what dragana thinks.

We want to cancel the transport and transaction without transport trying to recover (RecoverFromError)?

Or we want RecoverFromError to check for other ip addresses?

If we want to skip RecoverFromError we can just check in RecoverFromError if the out/input streams have been canceled as well. If socket times out during CONNECTING state, I think socket will be detached and in OnSocketDetached we call RecoverFromError. I think the error is set to the streams later (in OnSocketDetached if we do not decide to recover from error).
If we cancel the transport, the streams are canceled immediately.

If we want to RecoverFromError to check for other ip addresses we can simple only set mCondition to TIMEOUT and I think everything will work fine (But please check this). This will need a bit of rewriting of nsSocketTransport::Close.


I am not sure if the Patrick's suggestion will work.
Flags: needinfo?(dd.mozilla)
I can try the approach from comment 53 tomorrow. I can try both of them.
Depends on: 1364189
[Tracking Requested - why for this release]: This needs to go in with bug 1364189. Fix for sev1 blocker from partner.
status-firefox53: wontfix → ---
tracking-firefox53: --- → ?
They needthis bug landed on beta and release as well. I have nominated bug 1364189
Flags: needinfo?(honzab.moz)
(In reply to Dragana Damjanovic [:dragana] from comment #56)
> They needthis bug landed on beta and release as well. I have nominated bug
> 1364189

Thanks.  I will nominate, but I'm off my desktop for few days, so if merging is needed it will be hard.
Flags: needinfo?(honzab.moz)
Comment on attachment 8864182 [details] [diff] [review]
v1 (NS_ERROR_ABORT -> NS_ERROR_NET_TIMEOUT)

Approval Request Comment
[Feature/Bug causing the regression]: bug 878792
[User impact if decl1ined]: 90s timeout of a web server to accept a connectin leads to a blank page w/o an error explanation and lose of the URL entered/navigated to
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: would be good, comment 38
[List of other uplifts needed for the feature/fix]: bug 1364189 !
[Is the change risky?]: the risk is low, but there is some (personal opinion)
[Why is the change risky/not risky?]: low risk because: we caught why the regressive change has been added and is now fixed in a different way in bug 1364189
[String changes made/needed]: none
Attachment #8864182 - Flags: approval-mozilla-beta?
FWIW, this grafts cleanly to all affected branches.
status-firefox53: --- → affected
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(brindusa.tot)
I can check this bug.  I'm the original reporter.

Since it's OS dependent (kernel socket timeout defaults), it would make sense.

I can't check the websocket regressions.
Before

timeout after +- 90 seconds
browser document empty
url bar empty


Firefox 53 release (not nightly)

timeout after +- 90 seconds
browser document empty
url bar empty


2017-05-17-10-03-41-mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2

timeout after +- 180 seconds
browser document displays error message (with working "try again")
url bar has correct address
this is the desired result


2017-05-18-07-03-17-mozilla-release-l10n/firefox-53.0.3.zh-TW.linux-x86_64.tar.bz2

timeout after +- 90 seconds
browser document empty
url bar empty


2017-05-17-12-24-19-mozilla-esr52-l10n/firefox-52.1.2.en-GB.linux-x86_64.tar.bz2

timeout after +- 90 seconds
browser document empty
url bar empty
Attached image Clipboard01.jpg (obsolete) — 
how come his has not been fixed since firefox 52?
It is on release and causing data loss and no one here seems to bother to fix this?
Attachment #8869124 - Flags: feedback?
(In reply to Sami from comment #63)
> Created attachment 8869124 [details]
> Clipboard01.jpg
> 
> how come his has not been fixed since firefox 52?
> It is on release and causing data loss and no one here seems to bother to
> fix this?

Regressed in Firefox 25.  This is a risky change and it has already been decided to uplift only up to beta.  This is not a security bug to uplift to 52 (release and ESR).
Blocks: 878792
Attachment #8869124 - Attachment is obsolete: true
Attachment #8869124 - Flags: feedback?
(In reply to Berend De Schouwer from comment #1)
> This is a regression.  Firefox 52 has the problem.  Firefox 51 keeps the URL
> bar with the relevant information.

Read this!!
(In reply to Honza Bambas (:mayhemer) from comment #64)
> (In reply to Sami from comment #63)
> > Created attachment 8869124 [details]
> > Clipboard01.jpg
> > 
> > how come his has not been fixed since firefox 52?
> > It is on release and causing data loss and no one here seems to bother to
> > fix this?
> 
> Regressed in Firefox 25.  This is a risky change and it has already been
> decided to uplift only up to beta.  This is not a security bug to uplift to
> 52 (release and ESR).

Just tested Firefox 51 does not have this bug.
(In reply to Sami from comment #65)
> (In reply to Berend De Schouwer from comment #1)
> > This is a regression.  Firefox 52 has the problem.  Firefox 51 keeps the URL
> > bar with the relevant information.
> 

Ah, yes.  This has regressed from combination of two bugs, right.  One landed on 52 and one on 25 (a ticking bomb).  Still, this is not qualified to be uplifted to 52, IMO, sorry.  We could ask the release drivers (those having the final word) to uplift both bugs, but I highly doubt they decide to take them.
(In reply to Honza Bambas (:mayhemer) from comment #66)
> (In reply to Sami from comment #65)
> > (In reply to Berend De Schouwer from comment #1)
> > > This is a regression.  Firefox 52 has the problem.  Firefox 51 keeps the URL
> > > bar with the relevant information.
> > 
> 
> Ah, yes.  This has regressed from combination of two bugs, right.  One
> landed on 52 and one on 25 (a ticking bomb).  Still, this is not qualified
> to be uplifted to 52, IMO, sorry.  We could ask the release drivers (those
> having the final word) to uplift both bugs, but I highly doubt they decide
> to take them.

Thank you for understanding.
ESR52 is long term release and the bug is there so imho it should be fixed s esr focuses on stability.
and this 
Bug 1352447

seems similar.

Please reconsider for stability for Long supported release or data loss will keep happening on it till the next long term release which has radical changes and people might now switch right then.
Flags: needinfo?(honzab.moz)
Flags: needinfo?(dd.mozilla)
Redirect comment 67 to Gary Chang (the ESR release driver).
Flags: needinfo?(honzab.moz)
Flags: needinfo?(gchang)
Flags: needinfo?(dd.mozilla)
Depends on: 798249
Comment on attachment 8864182 [details] [diff] [review]
v1 (NS_ERROR_ABORT -> NS_ERROR_NET_TIMEOUT)

Fix a regression. Beta54+. Should be in 54 beta 10.

Redirect NI to Ritu as ESR owner.
Flags: needinfo?(gchang) → needinfo?(rkothari)
Attachment #8864182 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1366203
Flags: qe-verify+
Hi Honza, should we consider uplifting this fix to ESR52? It seems like a bad regression.
Flags: needinfo?(rkothari) → needinfo?(honzab.moz)
(In reply to Ritu Kothari (:ritu) from comment #72)
> Hi Honza, should we consider uplifting this fix to ESR52? It seems like a
> bad regression.

This is funny :)  The decision making has made a circle back to me, nice.  This depends also on landing bug 1364189 which status is kinda unclear to me.  But when we consider it safe to uplift both, then yes, we should.

(leaving ni on me)
Comment on attachment 8864182 [details] [diff] [review]
v1 (NS_ERROR_ABORT -> NS_ERROR_NET_TIMEOUT)

comment 58
Flags: needinfo?(honzab.moz)
Attachment #8864182 - Flags: approval-mozilla-esr52?
This still is happening to me :(

on today's build. Not very technically adept but tried to reproducing it often 
Filed Bug 1367123 & Bug 1367131

This might be related IDK

Bug 1366203
Flags: needinfo?(rkothari)
Flags: needinfo?(honzab.moz)
(In reply to shellye from comment #75)
> This still is happening to me :(
> 
> on today's build. Not very technically adept but tried to reproducing it
> often 
> Filed Bug 1367123 & Bug 1367131
> 
> This might be related IDK
> 
> Bug 1366203

No idea what you want from me.
Flags: needinfo?(honzab.moz)
(In reply to Honza Bambas (:mayhemer) from comment #76)
> (In reply to shellye from comment #75)
> > This still is happening to me :(
> > 
> > on today's build. Not very technically adept but tried to reproducing it
> > often 
> > Filed Bug 1367123 & Bug 1367131
> > 
> > This might be related IDK
> > 
> > Bug 1366203
> 
> No idea what you want from me.

Ummm that the bug is not properly fixed?
needs to be properly fixed and tested?

Sorry no idea how things work here
Hi Shellye, this is fixed on Nightly. Did you test this against the latest Nightly build?
Flags: needinfo?(rkothari) → needinfo?(shellye5)
(In reply to Ritu Kothari (:ritu) from comment #78)
> Hi Shellye, this is fixed on Nightly. Did you test this against the latest
> Nightly build?

Yes did on today's build on vanilla profile, please see above comment bug 1354796#c75 & the bugs filed with all the details(sorry not very knowledgeable about browsers and it's workings)
Flags: needinfo?(shellye5) → needinfo?(rkothari)
Thanks Shellye. We will let someone from our QA team try to repro this scenario based on STR in description/comment 0. Your other bugs will be triaged as well.
Flags: needinfo?(rkothari)
(In reply to Ritu Kothari (:ritu) from comment #80)
> Thanks Shellye. We will let someone from our QA team try to repro this
> scenario based on STR in description/comment 0. Your other bugs will be
> triaged as well.

Shukriya ma'am 

pretty sure that this was a security fix from

https://www.mozilla.org/en-US/security/advisories/mfsa2016-85/

one of those which was triggered to cause this issue in Firefox 52 cycle.

**To me it's this**

Bug 1284395 (CVE-2017-5420)

Pretty sure it's this bug which caused all havoc with the help of one of the fixes in mfsa2016-85

maybe back out this patch (privately)
and try if the problem occurs and provide a test build with the patches and band-aid fixes revoked from them,
can test it if you want help.


More info how that fix might have broken stuff
and help the QA team
bug 1284395#c23

Bug 1247968

bug 1352447#c7

bug 610357#c118
Flags: needinfo?(rkothari)
Can we try to get another set of eyes on this on Nightly & Beta to see if SV can also still reproduce?
Flags: needinfo?(rares.bologa)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #82)
> Can we try to get another set of eyes on this on Nightly & Beta to see if SV
> can also still reproduce?

If it's any help can reproduce this on beta & Today's build.
Flags: needinfo?(ryanvm)
This is already on our todo list. Clearing ni?s since we're already tracking qe-verify+ bugs on 54.
Flags: needinfo?(rares.bologa)
Flags: needinfo?(brindusa.tot)
No longer depends on: 1366203
See Also: → 1366203
(In reply to Andrei Vaida [:avaida], Desktop Release QA – please ni? me from comment #84)
> This is already on our todo list. Clearing ni?s since we're already tracking
> qe-verify+ bugs on 54.

The point was to get a more immediate check so we could make a decision regarding uplift to ESR52, not a "when you happen to get to it" check that still hasn't happened two weeks later.
Flags: needinfo?(ryanvm) → needinfo?(andrei.vaida)
We don't have QA verification on this one yet, let's leave the esr uplift nom as is and take this in ESR52.3. This is a wontfix for ESR52.2.
tracking-firefox-esr52: --- → 55+
After trying all the steps that were mentioned in comments I'm afraid I was unable to reproduce this issue on old build (Fx 52.0 53.0) where the fix has not been pushed, so I can't verify it in latest 54 and Nightly builds.
Flags: needinfo?(andrei.vaida)
I'm dropping qe-verify+ since I could not reproduce the initial issue.

Berend De Schouwer, would you be so kind and verify that this issue does not reproduce with Firefox 54.0?

build: https://archive.mozilla.org/pub/firefox/candidates/54.0-candidates/build3/
Flags: qe-verify+ → needinfo?(berend.de.schouwer)
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #88)
> I'm dropping qe-verify+ since I could not reproduce the initial issue.
> 
> Berend De Schouwer, would you be so kind and verify that this issue does not
> reproduce with Firefox 54.0?
> 
> build:
> https://archive.mozilla.org/pub/firefox/candidates/54.0-candidates/build3/

That build looks good.
Flags: needinfo?(berend.de.schouwer)
(In reply to Berend De Schouwer from comment #89)
> (In reply to Bogdan Maris, QA [:bogdan_maris] from comment #88)
> > I'm dropping qe-verify+ since I could not reproduce the initial issue.
> > 
> > Berend De Schouwer, would you be so kind and verify that this issue does not
> > reproduce with Firefox 54.0?
> > 
> > build:
> > https://archive.mozilla.org/pub/firefox/candidates/54.0-candidates/build3/
> 
> That build looks good.

Thanks! Marking accordingly.
status-firefox54: fixed → verified
status-firefox55: fixed → verified
Comment on attachment 8864182 [details] [diff] [review]
v1 (NS_ERROR_ABORT -> NS_ERROR_NET_TIMEOUT)

Meets the triage bar, ESR52+
Attachment #8864182 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
Hi Berend, could you please verify this on 52.3.0 ESR [1] as well? I'd really appreciate it.

[1] https://archive.mozilla.org/pub/firefox/candidates/52.3.0esr-candidates/build1/
Flags: needinfo?(berend.de.schouwer)
Confirmed fixed in 52.3.0 ESR, Build 1.
Flags: needinfo?(berend.de.schouwer)
(In reply to Berend De Schouwer from comment #94)
> Confirmed fixed in 52.3.0 ESR, Build 1.

Thanks a lot, Berend!
status-firefox-esr52: fixed → verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: