Closed Bug 704008 Opened 14 years ago Closed 13 years ago

Seamonkey fails to appear onscreen if internet connection is disconnected

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 2.3 Branch
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: losepete, Unassigned)

Details

User Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:6.0.2) Gecko/20110905 Firefox/6.0.2 SeaMonkey/2.3.3 Build ID: 20110905145903 Steps to reproduce: I started Seamonkey. Actual results: A few bumps showed on the System Activity Monitor (cpu activity) and the timer appeared onscreen then... nothing. I tried again but Seamonkey did not start. Investigation revealed Seamonkey was not in the Window List but was in the Process List. I killed the existing Seamonkey and retried. Nothing - except Seamonkey again appeared in the Process List but not the Window List. I killed Seamonkey and tried a different Profile. Same results as above. I then tried another Profile that is used for CUPS Admin purposes and Seamonkey appeared onscreen. Here it is worth noting that this Profile has a home page that does *not* need an active internet connection. Wondering if something had glitched in 2 Profiles I closed Seamonkey and then tried to start Seamonkey with this Profile (losepete) in safe mode. Seamonkey appeared but could not load the home page. Further investigation revealed that my internet connection had died. "Rebooting" cable modem and router resolved that issue. I closed Seamonkey and then restarted with this Profile without problems. So, I conclude that at some point recently some code has changed that prevents Seamonkey loading a Profile if the home page for that Profile is not accessible. My reason for this conclusion is that I have not previously seen Seamonkey refuse to start if it cannot load a home page due to a failed internet connection. Is there some sort of valid reason for this change? - and does Seamonkey 2.5 behave in the same manner? Expected results: Seamonkey should have appeared onscreen and delivered some sort of "cannot connect" message. This problem can be reproduced by simply disconnecting the network cable on my system and then starting Seamonkey. This results, as below, in Seamonkey failing to appear onscreen - not in the Window List but is in the Process List. So, Seamonkey is starting but does not appear onscreen because the home page is not accessible.
I have never seen this problem on Linux, if I pull off the cable or switch off wireless, I get the error page (with "Adress Not Found"). What is not clear to me from your description: did you try with a fresh profile instead of just different existing ones?
Hardware: Other → x86
Hi Peter I created a new Profile, changed the Cache value to 0 and selected the "welcome to seamonkey 2.3.3" page as home page. I closed Seamonkey, got a coffee and then started Seamonkey with the new Profile. Seamonkey appears onscreen immediately on starting and continues attempting to connect until finally it gives the "address not found" message. Retesting Profiles that I reported as failed: When I start Seamonkey it does not appear onscreen immediately. It does eventually appear - between 2 and 3 minutes after starting - and display the "address not found" message. Seems that for whatever reason these 2 Profiles do not allow Seamonkey to appear onscreen until Seamonkey is ready to display the "address not found" message. Any ideas on why this should be?
(In reply to Peter Brown from comment #2) > Retesting Profiles that I reported as failed: > > When I start Seamonkey it does not appear onscreen immediately. It does > eventually appear - between 2 and 3 minutes after starting - and display the > "address not found" message. Seems that for whatever reason these 2 Profiles > do not allow Seamonkey to appear onscreen until Seamonkey is ready to > display the "address not found" message. Any ideas on why this should be? You could try using iptrace (see the tcpip manual) to examine the network traffic. Close SeaMonkey right after it starts to stop the trace file getting huge.
Hi Dave I now have an iptrace.dmp file which I used this command on to generate human readable text: ipformat iptrace.dmpt > iptrace.txt Now the question becomes: What am I looking for in this iptrace.txt log file?
Hmm. Possibly related? Bug 703374 - browser.cache.memory.enable set to false causes pages to fail to load
Not related as about:config shows browser.cache.memory.enable set to true.
Presuming that it is something "munged" in the 2 Profiles that suffer from this problem what should I be looking for within these 2 Profiles that could cause the problem? I ask because I am now using Seamonkey 2.6 and this has the same problem if started when there is no internet connection. I have unchecked the automatically check for updates for both Seamonkey and Addons in Preferences with no change in behaviour. Daves suggestion of creating an iptrace.dmp file and then having a look through sounded promising - but I have no idea what I'm looking for...
Peter, is this still present under 2.7.2? If so, you might try diff'ing the prefs.js files against one another to narrow this down. Are you using a proxy? Check your extensions, as you may have something which is trying to establish a connection before the browser window has been drawn, and until that times out, the browser remains "invisible." If you do find that this is extension or profile related, other than a default profile setting (which apparently this is not), it's probably best to close this as INVALID.
Hi Lewis No idea if this is present in 2.7.2 as I am still using 2.6 and do not plan on updating Seamonkey until a few of the "wrinkles" in later versions are cured. No. no Proxy in use. It is very possible that the problem is an Extension (or several) "dialing home". What is the best way to check for this? - Preferences, Software Installation, Automatically check for updates is Unchecked (Off) so, surely, none of the Extensions should be "dialing home". The suggestion of using iptrace would have been a good one - except I have no idea what I am supposed to be looking for in the dmp file. Do you?
(In reply to Peter Brown from comment #9) > The suggestion of using iptrace would have been a good one - except I have > no idea what I am supposed to be looking for in the dmp file. Do you? Sorry for getting distracted. Look for DNS lookups and what domain they are looking up. You can also look at the IP addresses and use something like nslookup to find out who owns them. nslookup 192.168.0.1 for example.
Peter, following onto what Dave has suggested: 1. Open an OS/2 window & issue iptrace lan# <Enter> (where # is the interface number). 2. Start SeaMonkey (you should note traffic in the OS/2 window). 3. In the OS/2 window, issue a Ctrl-C. 4. In the OS/2 window, run ipformat > iptrace.txt <Enter>. 5. Open iptrace.txt in your favorite editor, and look for clues (see below). Here's a snippet from an iptrace I just ran here. Note that my IP address is currently 192.168.100.24, my primary DNS is 192.168,.100.1, my firewall is 291.168.100.201, and my mail server is 192.168.100.2: Opening IPTRACE.DMP ... Sucessful Reading packet headers ... 31 headers read. PreProcess packet info -------------------------- #:1 -------------------------- Delta Time: 0.000sec Packet Length: 64 bytes (40 hex) DIX: Dest: 00:01:6C:CB:F4:80 Source: 00:08:02:25:08:34 -------------------------- ARP -------------------------- ARP: Hardware Type:1 (Ethernet 10Mb) ARP: Protocol Type:0800 (IP Address) ARP: Hardware Len:6 ARP: Protocol Len:4 ARP: Operation:1 (ARP Request) ARP: Sender HW address: 000802250834 ARP: Sender PA: 192.168.100.001. ARP: Target HW address: 00016CCBF480 ARP: Target PA: 192.168.100.024. -------------------------- #:2 -------------------------- Delta Time: 0.000sec Packet Length: 64 bytes (40 hex) DIX: Dest: 00:08:02:25:08:34 Source: 00:01:6C:CB:F4:80 -------------------------- ARP -------------------------- ARP: Hardware Type:1 (Ethernet 10Mb) ARP: Protocol Type:0800 (IP Address) ARP: Hardware Len:6 ARP: Protocol Len:4 ARP: Operation:2 (ARP Response) ARP: Sender HW address: 00016CCBF480 ARP: Sender PA: 192.168.100.024. ARP: Target HW address: 000802250834 ARP: Target PA: 192.168.100.001. -------------------------- #:3 -------------------------- Delta Time: 0.000sec Packet Length: 64 bytes (40 hex) DIX: Dest: 00:08:02:25:08:34 Source: 00:01:6C:CB:F4:80 -------------------------- ARP -------------------------- ARP: Hardware Type:1 (Ethernet 10Mb) ARP: Protocol Type:1000 ARP: Hardware Len:6 ARP: Protocol Len:4 ARP: Operation:2 (ARP Response) ARP: Sender HW address: 00016CCBF480 ARP: Sender PA: 192.168.100.024. ARP: Target HW address: 000802250834 ARP: Target PA: 192.168.100.001. -------------------------- #:4 -------------------------- Delta Time: 0.506sec Packet Length: 114 bytes (72 hex) DIX: Dest: 00:01:6C:CB:F4:80 Source: 00:0E:7F:5F:07:7E DIX: Dest: 192.168.100.024 Source: 192.168.100.002 ----------------------- IP HEADER ----------------------- IP: Version: 4 Correct Header Length: 20 bytes IP: Type Of Service: 00 IP: 000. .... Routine IP: ...0 .... Normal Delay IP: .... 0... Normal Throughput IP: .... .0.. Normal Reliability IP: Total Len: 100 (x64) bytes Id: B961 IP: Flags: 0 IP: .0.. May Fragment IP: ..0. Last Fragment IP: Fragment Offset: 000 IP: Time To Live: 64 sec Protocol: 6 TCP IP: Header Checksum: 77C7 (Correct) IP: No Options ---------------------- TCP HEADER ---------------------- TCP: Source Port: 143 (Unassigned port) Dest Port: 62020 (Unassigned port) TCP: Sequence #: 844507643 TCP: Ack #: 3700748785 TCP: Offset: 32 bytes TCP: Flags: 18 TCP: ..0. .... Urgent bit Off TCP: ...1 .... <ACK> Ack bit On TCP: .... 1... <PUSH>Push bit On TCP: .... .0.. Reset bit Off TCP: .... ..0. Synchronize bit Off TCP: .... ...0 Finish bit Off TCP: Window: 33304 Checksum: 926E (Correct) TCP: Option Code: 01 Length: 1 bytes [NOP] TCP: No Operation TCP: Option Code: 01 Length: 1 bytes [NOP] TCP: No Operation TCP: Option Code: 08 Length: 10 bytes [TIMESTAMP] TCP: TimeStamp Value 866036 (xD36F4) TCP: TimeStamp Echo Reply 131166 (x2005E) --------------------------------- DATA ----------------------------------- 0000 17 03 01 00 2B 53 48 4C EF 8C 2B 52 AF 87 53 D6 ....+SHL..+R..S. 0010 6C F4 55 40 8F 96 90 D5 56 67 02 03 96 19 47 6C l.U@....Vg....Gl 0020 9F 7D 1C E8 BB 9A 51 D1 67 18 BE 5B 60 31 B1 9D .}....Q.g..[`1.. -------------------------- #:5 -------------------------- Delta Time: 0.002sec Packet Length: 93 bytes (5D hex) DIX: Dest: 00:0E:7F:5F:07:7E Source: 00:01:6C:CB:F4:80 DIX: Dest: 192.168.100.002 Source: 192.168.100.024 ----------------------- IP HEADER ----------------------- IP: Version: 4 Correct Header Length: 20 bytes IP: Type Of Service: 00 IP: 000. .... Routine IP: ...0 .... Normal Delay IP: .... 0... Normal Throughput IP: .... .0.. Normal Reliability IP: Total Len: 79 (x4F) bytes Id: 0C55 IP: Flags: 0 IP: .0.. May Fragment IP: ..0. Last Fragment IP: Fragment Offset: 000 IP: Time To Live: 64 sec Protocol: 6 TCP IP: Header Checksum: 24E9 (Correct) IP: No Options ---------------------- TCP HEADER ---------------------- TCP: Source Port: 62020 (Unassigned port) Dest Port: 143 (Unassigned port) TCP: Sequence #: 3700748785 TCP: Ack #: 844507691 TCP: Offset: 32 bytes TCP: Flags: 18 TCP: ..0. .... Urgent bit Off TCP: ...1 .... <ACK> Ack bit On TCP: .... 1... <PUSH>Push bit On TCP: .... .0.. Reset bit Off TCP: .... ..0. Synchronize bit Off TCP: .... ...0 Finish bit Off TCP: Window: 33304 Checksum: 3ABE (Correct) TCP: Option Code: 01 Length: 1 bytes [NOP] TCP: No Operation TCP: Option Code: 01 Length: 1 bytes [NOP] TCP: No Operation TCP: Option Code: 08 Length: 10 bytes [TIMESTAMP] TCP: TimeStamp Value 131347 (x20113) TCP: TimeStamp Echo Reply 866036 (xD36F4) --------------------------------- DATA ----------------------------------- 0000 17 03 01 00 16 37 18 49 E5 A1 D9 AB BB 83 BE 12 .....7.I........ 0010 9E EE 45 84 2A 17 07 4E 75 26 10 ..E.*..Nu&. What you see is an IMAP exchange (port 143) between my ThinkPad and my mail server, after looking up its name against the DNS server (as it's local to me, I did not need to traverse the firewall, so no traffic directed at 192.168.100.201 is present). What you would be looking to see is some lookup (most likely) and then the lack of a response (when the cable is disconnected). With the cable connected, a DNS reply should come back and you should see traffic on some port headed out and returning. To test extensions, go into the Add-ons Manager and disable each of your extensions, restart SeaMonkey, and see if the behavior is different. Then, either re-enable half of them and test again to narrow it down, or go one at a time until you hit on the one causing the trouble (assuming the behavior is indeed different with all of them disabled). HTH
Hi Lewis and Dave Thanks for the iptrace instructions. I pulled my network lead from the router and gave it a try. I started iptrace without parameters which defaults to lan0 plus loopback interface and started Seamonkey. I watched some detail being output onscreen but did not see anything that I think is unusual and stopped iptrace after around 30 seconds. Seamonkey finally appeared onscreen with the "failed to connect" message after around 2 minutes. The results in iptrace.txt show my ip address trying to contact the router ip address plus several attempts to contact 192.168.001.255 which is the last (and unused) ip address on the network. There are no attempts to contact DNS servers showing in the dump file.
(In reply to Peter Brown from comment #12) [...] > > The results in iptrace.txt show my ip address trying to contact the router > ip address plus several attempts to contact 192.168.001.255 which is the > last (and unused) ip address on the network. There are no attempts to > contact DNS servers showing in the dump file. Your router probably has a DNS server builtin. Try again with your router connected.
Hi Dave I guess I should have pulled the WAN lead rather than the LAN lead... (No, the router does not have an inbuilt DNS) Different results and the only ip address that is not my ip address, the router or either of the DNS servers is 239.255.255.250 nslookup reports:- [L:\MPTN\BIN]nslookup 239.255.255.250 Server: cache1.service.virginmedia.net Address: 194.168.4.100 *** cache1.service.virginmedia.net can't find 239.255.255.250: Non-existent host /domain Using several "whois" queries the only thing I can find out about this ip address is:- Net Type IANA Special Use Comments This block is reserved for special purposes. Please see RFC 3171 for additional information. I had a look at rfc3171 http://www.rfc-editor.org/rfc/rfc3171.txt and am none the wiser as to why my system wants to contact that ip address...
Pete, 239.255.255.250 is the IPv4 multicast address for SSDP. See https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol . Do you happen to have a media player extension or other type app installed and running on the machine? These are common things which utilize SSDP. Contrast these findings with a clean (fresh) profile, which you mentioned before does not delay in drawing the browser window, and that should help you narrow down the cause. I don't think this is a SeaMonkey bug.
Hi Lewis As this 1st occurred before installing Flash I think, for once :-), I can discount the Flash plugin as the cause. That leaves the following plugins: mplayer and npdsmi Neither of these have caused this problem in the past. I guess I could Disable or Uninstall them and see what happens.
hi I deleted npmp.dll and npdsmi.dll from the plugins directory and retested. No change. So, looks like something in my Profile. The question is what... Looking through about:config I do not see anything obvious. I do see some lines for dwhelper and am not sure what that is. Using Google I see that it is a download helper extension for Firefox that I think I installed a while back and then uninstalled. Looks like uninstalling this extension does not remove the Profile configuration - seems a typical Windows way of doing things. I closed Seamonkey and edited prefs.js to delete all dwhelper lines and retested. No change. Any idea what I should be looking for in about:config ?
Hi All I Disabled all Extensions and tested. The unknown ip address 239.255.255.250 does not appear in the iptrace generated. I added extensions back a few at a time and eventually found that FlashBlock is responsible for the unknown ip address 239.255.255.250 Why would FlashBlock need to contact this ip address? - There is no FlashBlock setting for Enabling/Disabling UPnP. However, it seems the problem is not a Seamonkey problem so I guess I need to ask the FlashBlock guys what is going on.
Closed per Comment 18
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.