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)
Tracking
()
People
(Reporter: berend.de.schouwer, Assigned: mayhemer)
References
Details
(Keywords: dataloss, regression, Whiteboard: [necko-active])
Attachments
(1 file, 1 obsolete file)
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.
Reporter | ||
Comment 1•7 years ago
|
||
This is a regression. Firefox 52 has the problem. Firefox 51 keeps the URL bar with the relevant information.
Reporter | ||
Comment 2•7 years ago
|
||
This was opened as not-a-duplicate of #610537 at the request of Dão Gottwald
Reporter | ||
Comment 3•7 years ago
|
||
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.
Reporter | ||
Comment 4•7 years ago
|
||
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.
Reporter | ||
Comment 5•7 years ago
|
||
(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
Comment 6•7 years ago
|
||
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)
Updated•7 years ago
|
Component: Untriaged → Location Bar
Reporter | ||
Comment 7•7 years ago
|
||
So what would be the nightly dates for 52 and 51?
Comment 8•7 years ago
|
||
(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
Comment 9•7 years ago
|
||
(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).
Reporter | ||
Comment 10•7 years ago
|
||
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)
Updated•7 years ago
|
Blocks: CVE-2017-5420
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
status-firefox52:
--- → wontfix
status-firefox53:
--- → wontfix
status-firefox54:
--- → affected
status-firefox55:
--- → affected
Ever confirmed: true
Keywords: regressionwindow-wanted
Comment 11•7 years ago
|
||
why will this not be fixed in esr52? It's a long term release.
Comment 12•7 years ago
|
||
(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.
Comment 13•7 years ago
|
||
(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)
Comment 14•7 years ago
|
||
[Tracking Requested - why for this release]: Recent UX / dataloss regression affecting primary UI https://hg.mozilla.org/mozilla-central/rev/a45cfe898352daa445ebc702273c73c56b3ef3a1 is Gijs' baby
Comment 15•7 years ago
|
||
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)
Reporter | ||
Comment 16•7 years ago
|
||
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)
Reporter | ||
Comment 17•7 years ago
|
||
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.
Comment 18•7 years ago
|
||
(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)
Reporter | ||
Comment 19•7 years ago
|
||
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.
Comment 20•7 years ago
|
||
(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?
Reporter | ||
Comment 21•7 years ago
|
||
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)
Reporter | ||
Comment 22•7 years ago
|
||
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.
Reporter | ||
Comment 23•7 years ago
|
||
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...)
Comment 24•7 years ago
|
||
(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. :-)
Assignee | ||
Comment 25•7 years ago
|
||
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)
Comment 26•7 years ago
|
||
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)
Comment 27•7 years ago
|
||
thanks for digging in, providing logs, etc.. everyone.
Comment 28•7 years ago
|
||
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
Comment 29•7 years ago
|
||
(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?
Comment 30•7 years ago
|
||
(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
Comment 31•7 years ago
|
||
(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?
Updated•7 years ago
|
Whiteboard: [necko-next]
Comment 33•7 years ago
|
||
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).
Comment 34•7 years ago
|
||
(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)
Comment 35•7 years ago
|
||
(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)
Comment 36•7 years ago
|
||
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)
Assignee | ||
Comment 37•7 years ago
|
||
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]
Assignee | ||
Comment 38•7 years ago
|
||
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)
Updated•7 years ago
|
Attachment #8864182 -
Flags: review?(mcmanus) → review+
Assignee | ||
Updated•7 years ago
|
Keywords: checkin-needed
Comment 39•7 years ago
|
||
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
Comment 40•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/fbad88a61127
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Comment 41•7 years ago
|
||
Should we consider this for uplift or can it ride the 55 train?
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 42•7 years ago
|
||
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)
Comment 43•7 years ago
|
||
From comment 1, it looks like this is a regression, even though not a recent one.
Comment 45•7 years ago
|
||
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.
Assignee | ||
Comment 46•7 years ago
|
||
(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...
Assignee | ||
Comment 47•7 years ago
|
||
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)
Comment 48•7 years ago
|
||
(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.
Comment 49•7 years ago
|
||
plus will this fix bug 610357 ? both were regressed in 52...
Flags: needinfo?(honzab.moz)
Comment 50•7 years ago
|
||
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)
Assignee | ||
Comment 51•7 years ago
|
||
(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)
Comment 52•7 years ago
|
||
Since this issue has been there for a while and the patch may bring back bug 878792. Mark 54 fix-optional.
Comment 53•7 years ago
|
||
(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)
Comment 54•7 years ago
|
||
I can try the approach from comment 53 tomorrow. I can try both of them.
Comment 55•7 years ago
|
||
[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:
--- → ?
Comment 56•7 years ago
|
||
They needthis bug landed on beta and release as well. I have nominated bug 1364189
Flags: needinfo?(honzab.moz)
Assignee | ||
Comment 57•7 years ago
|
||
(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)
Assignee | ||
Comment 58•7 years ago
|
||
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?
Comment 59•7 years ago
|
||
FWIW, this grafts cleanly to all affected branches.
status-firefox53:
--- → affected
Comment 60•7 years ago
|
||
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)
Reporter | ||
Comment 61•7 years ago
|
||
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.
Reporter | ||
Comment 62•7 years ago
|
||
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
Comment 63•7 years ago
|
||
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?
Assignee | ||
Comment 64•7 years ago
|
||
(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
Assignee | ||
Updated•7 years ago
|
Attachment #8869124 -
Attachment is obsolete: true
Attachment #8869124 -
Flags: feedback?
Comment 65•7 years ago
|
||
(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.
Assignee | ||
Comment 66•7 years ago
|
||
(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.
Comment 67•7 years ago
|
||
(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)
Assignee | ||
Comment 68•7 years ago
|
||
Redirect comment 67 to Gary Chang (the ESR release driver).
Flags: needinfo?(honzab.moz)
Flags: needinfo?(gchang)
Flags: needinfo?(dd.mozilla)
Comment 69•7 years ago
|
||
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+
Comment 70•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/0a1b96abe72e
Updated•7 years ago
|
Flags: qe-verify+
Comment 71•7 years ago
|
||
Too late to fix in 53.
Hi Honza, should we consider uplifting this fix to ESR52? It seems like a bad regression.
Flags: needinfo?(rkothari) → needinfo?(honzab.moz)
Assignee | ||
Comment 73•7 years ago
|
||
(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)
Assignee | ||
Comment 74•7 years ago
|
||
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?
Comment 75•7 years ago
|
||
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)
Assignee | ||
Comment 76•7 years ago
|
||
(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)
Comment 77•7 years ago
|
||
(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)
Comment 79•7 years ago
|
||
(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)
Comment 81•7 years ago
|
||
(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)
Flags: needinfo?(rkothari)
Comment 82•7 years ago
|
||
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)
Comment 83•7 years ago
|
||
(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)
Comment 84•7 years ago
|
||
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)
Comment 85•7 years ago
|
||
(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+
Comment 87•7 years ago
|
||
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)
Comment 88•7 years ago
|
||
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)
Reporter | ||
Comment 89•7 years ago
|
||
(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)
Comment 90•7 years ago
|
||
(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.
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+
Comment 92•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-esr52/rev/69d1a9de76b9
Comment 93•7 years ago
|
||
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)
Reporter | ||
Comment 94•7 years ago
|
||
Confirmed fixed in 52.3.0 ESR, Build 1.
Flags: needinfo?(berend.de.schouwer)
Comment 95•7 years ago
|
||
(In reply to Berend De Schouwer from comment #94) > Confirmed fixed in 52.3.0 ESR, Build 1. Thanks a lot, Berend!
Updated•7 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•