Closed Bug 454381 Opened 16 years ago Closed 16 years ago

Minefield Nightly brings up Dial-Up Login if a website is unavailable

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.1b2

People

(Reporter: malzilla, Assigned: mayhemer)

References

Details

(Keywords: fixed1.9.1, regression)

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080908091724 Minefield/3.1b1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080908091724 Minefield/3.1b1pre Since the fix for Bug 452775 landed. If I try to navigate to a site that is unavailable. A Dial-Up Login box comes up even though I am still connected. Reproducible: Always Steps to Reproduce: 1.Click on Bookmark or Link thats off-line or down 2.A dial-Up Login Box is shown even though you are still connected 3.And then the "Web site is Unavailable" warning appears (at the same time) Expected Results: "Web site is Unavailable" warning appears And no Dial_Up login showing because the connection is still Active
Component: General → Networking
Depends on: 452775
Keywords: regression
Product: Firefox → Core
Version: unspecified → Trunk
No longer depends on: 452775
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
Just a note, the behavior described in bug 452775 comment 10 is reproducible with FF 3.0.1. And what is more annoying: the dial-up dialog is hidden behind the FF window and until I do Alt-Tab and close it no other load of any other page works and it seems like the local or provider connection is completely down. The decision when the dialog have to pop-up is IMHO wrong - it is pop-up on any load failure. Probably adding a condition to do this just in case of being offline (actually means that there is no IP assigned to any adapter) is one good step but maybe still not enough.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Minefield/3.1b1pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910003607 SeaMonkey/2.0a1pre A Dial-Up Login box comes up even though I am still connected, when I click some links on a page. If it happens it is reproducable. Another example: a gallery. Dial-Up Login box comes up every time I click an arrow to get the next image: http://ngm.nationalgeographic.com/2008/09/sailfish/nicklen-photography
http://ngm.nationalgeographic.com/2008/09/sailfish/nicklen-photography http://blog.wired.com/wiredscience/2008/08/mccains-vp-want.html and following links over there still showing bug in Minefield, but not in Seamonkey. When I follow the Links on this page a Dial-Up Login box comes up even though I am still connected, but Minefield doesn't use the existing connection unless the login box is canceled or submitted. Submitting the Login doesn't open my 2nd ISDN channel, loading from the first continues after the box is gone. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910003607 SeaMonkey/2.0a1pre
Since the Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 nightly landed I am now getting a Dial-Up Login box on browser start up after the Login is successful even though I have the bog standard google search page as my home page. So something has changed (for the worse)
We should rather back out the original bug than ship with this :-(
Assignee: nobody → honzab
Flags: blocking1.9.1? → blocking1.9.1+
Attached patch v1 (obsolete) (deleted) — Splinter Review
We fall to dialup only when link us down. I am not sure how this is gonna behave on linux (have no linux machine). Maybe better way would be to run dialup when link is not up - i.e. is down or unknown. I was testing this on mac but I don't know how to force modem connection even from Safari. FF3.1b1 also doesn't push modem to connect even the modem has been configured to automatically dial when needed. Anyway, this patch has no affect on mac.
Attachment #345884 - Flags: review?(benjamin)
QA Contact: general → networking
Attachment #345884 - Flags: review?(benjamin) → review?(cbiesinger)
Honza is it maybe an idea to try for another reviewer? I only ask because this is a really an awful "in your face" Bug on dial-up and is not going to look good for Beta 2.
Attachment #345884 - Flags: review?(cbiesinger) → review?(benjamin)
Comment on attachment 345884 [details] [diff] [review] v1 + // We cannot decide, expect the link is up expect -> assume? + mNetworkLinkService->GetIsLinkUp(&isLinkUp); needs an error check
Attachment #345884 - Flags: review?(benjamin) → review+
Attached patch v1.1 (deleted) — Splinter Review
addressed both comments.
Attachment #345884 - Attachment is obsolete: true
Attachment #346678 - Flags: superreview?(benjamin)
Attachment #346678 - Flags: approval1.9.1b2?
Comment on attachment 346678 [details] [diff] [review] v1.1 Not sure if this gets 1.9.1+, there is no automated test for this and I don't know how to create such a test. But scenario to test manually is quit simple.
Attachment #346678 - Flags: superreview?(benjamin) → superreview+
Comment on attachment 346678 [details] [diff] [review] v1.1 Let's make sure there's a Litmus test at least.
Flags: in-litmus?
Comment on attachment 346678 [details] [diff] [review] v1.1 a=beltzner
Attachment #346678 - Flags: approval1.9.1b2? → approval1.9.1b2+
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
Attachment #346678 - Flags: approval1.9.0.6?
Attachment #346678 - Flags: approval1.9.0.5?
Attachment #346678 - Flags: approval1.9.0.5?
Comment on attachment 346678 [details] [diff] [review] v1.1 Maybe we're missing something, but isn't this a regression fix for a bug that never landed in 3.0.x in the first place? minus for 1.9.0.6
Attachment #346678 - Flags: approval1.9.0.6? → approval1.9.0.6-
I experience this bug in Firefox 3.0.4 on daily bases and it slowly starts making me crazy.
Maybe cause of that bug is quit different but the bug is present on 1.9.0.4 branch. Probably I should build branch on the machine I can reproduce it and try to find out why it happens.
Daniel, you're right about the fact that it never landed in 3.0._0_, i. e. the public FF3.0 version shipped. It was definitely introduced in > 3.0.x.
sorry that should read > 3.0.0
It'd help to have a branch build that QA can reproduce with as well steps that reproduce this in 3.0.x builds. Barring that, I don't think we can approve this.
You just need to have a working connection to internet and a modem with setup connection (it may be just a fake, no need to have it really working). I also have checked option in IE to "Dial-up when connection is unavailable". It could be important, the dial up helper, as I recall, reads that options. Then any site like "www.jkahsdfkjhaefkjheafuihearfjkh.com" will carry out a dial-up box, hidden under the main FF window - what is the most annoying. I can also reproduce with Thunderbird 2.0.0.18, maybe also important information.
Al, can you take a look at this bug and see if you can reproduce based on comment 22?
Any news on this?
I just verified this using Firefox 3.0.4 on Windows XP. It only seems to reproduce if one has set the Connection settings in Internet Explorer to "Dial whenever a network connection is not present". If I set this and then try to load a non-existent site in Firefox 3.0.4, instead of giving me the typical failure message for a non-existent site, the dialog to dial the ISP will come up. Note: I installed 3.0 and saw the *exact* same behavior. This does not seem to be a recent regression and may simply be how Windows' tcp/ip connections want to handle failures when set up to dial on demand.
Thanks for this report Al. The same way behaves IE7, what more, when I press esc while dial-up dialog is open it switches to offline mode even I have a working local wired connection. Quit a stupid IMHO. This seems to be a windows bug. I will check to be sure the dialog is not open by Firefox but by windows itself. Question is, do WE like this behavior?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: