(In reply to Antonio Manuel Amaya Calvo from bug 769178 comment #7) > Dunno about blocker or not. I just lost an hour debugging something related > to this error though. Turns out that if you connect to a URL with a correct > certificate (say https://server.com) that then redirects you to a URL with > an incorrect certificate (trusted CA, bad name, say https://m.server.com) > you get the same 'URL invalid'... and when you click on the address bar it > shows https://server.com, NOT https://m.server.com which was the one that > actually failed. > > Probably not blocking, definitely irritating. Antonio, please share a URL that demonstrates this problem, if you have one. Also, is this B2G-specific or does it happen in Firefox Desktop and/or Firefox Mobile too?
Since the target channel didn't call OnStartRequest that would lead to OnLocationChange, the URL is not updated, since we didn't render the page. This could be an expected behavior. CC'ing bz to confirm/refute this. However, I really have to say we should change this behavior for few cases.
Indeed. In general, we want the url bar to match the content being shown in the browser tab, so no navigation means no location change.
OK, I was wrong. When the target page of the redirect has wrong certificate, the URL must be updated, since OnStartRequest *IS* called from the target load, however state of the channel is a failure. So, if the new URL did not appear, it was a bug. I made a simple local test for cases (current m-c): 1. redirect via regular http header 2. redirect by JS from head script 3. redirect by JS from onload 4. redirect by JS from onload+timeout All redirect from a valid ssl site to a site with the same cert but not matching domain (invokes an error page). They all correctly shows the target URL in the address bar + the error page.
Comment 4 tests were run in Firefox.
Moving to a different product and component based on comment 7.
Justin, do you think this might be caused by gecko not firing the mozbrowserlocationchange event in these circumstances?
(In reply to Ben Francis [:benfrancis] from comment #9) > Justin, do you think this might be caused by gecko not firing the > mozbrowserlocationchange event in these circumstances? That could be. It would be easy for you to test...
Ben how bad it is to not have this on V1
It would be nice to get security input on this. I'm wondering if it might be a wider issue with all kinds of errors preventing the address bar getting updated. It would need further investigation...
sec-review-needed (kw) is being depricated for sec-review? (flag) asking :pauljt as he has done much of the FxOS review work
In terms of rating this bug, I am more concerned about the spurious error message ("the address is invalid" ie bug 796362 and similar) than the behavior exhibited here - its annoying to debug, but I can't think of an exploitation case.
I cant reproduce this failure any more http://junk.arandomurl.com/invalid-ssl-redirect.html