From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 Hi, I'm using Mozilla 0.9.3 on WinNT4/SP6a on a PIII/450MHz and the entire application FREEZES if I access my bookmarks *for the first time* in any browser window. Subsequent accesses are OK. This consistently happens for me all the time in this release. It was not a problem in the previous releases. All I have to do to reproduce the problem is to create a new browser window (Ctrl+N) and click on the "Bookmarks" toolbar item - all windows then freeze for around 100 seconds and only then do I get to see the bookmarks. After that, *in the same window*, I can access my bookmarks relatively smoothly. Yes, I did search for similar bugs in Bugzilla and it turned up 88861 and 70670, which are quite similar and are perhaps related to this one, but I do not think so - like I said before, this was NOT a problem for me in the 0.9.2 or earlier releases. If you want, I can attach my current bookmarks (168K) if you think it is a result of some weird interaction with my bookmarks or the way they are organised (I have several levels/folders). Thanks for your patience and help, Ranjit Mathew (rmathew@hotmail.com) Reproducible: Always Steps to Reproduce: 1. Get a new Mozilla browser window (Ctrl+N or launch app) 2. Click on the "Bookmarks" toolbar Actual Results: Mozilla (all windows) FREEZES for around 100 seconds Expected Results: The bookmarks menu should snappily drop down. If you think it is a problem with my bookmarks, I would attach the file (168K).

Sorry, I forgot to add another observation: when this freeze happens, I'm able to switch to other applications, except that an approx. 200x70 sized part of the display from the "offending" Mozilla window remains (my display resolution is 800x600 @ 16-bits), i.e. the "switched-to" application's display is not updated in that area. The thing disappears after some time and I know that Mozilla has come out of the freeze. Ranjit.

*sigh* No one bothered to even touch this bug... :-( Anyways, I was able to trace the problem to two bookmarks that referred to machines on our network that I was NOT authenticated to. For example, the URL: file://///ASPWAS/db2docs/index.htm for our local IBM DB2 documentation index. If I'm not authenticated to the server "ASPWAS", the said problem appears. Of course, the workaround has been to remove such URLs from my bookmarks or (as I have done) write an "autologon" batch file that logs me to all the servers when I log on to WinNT. But I would still consider this a bug - this is not at all a problem with Netscape 4.7x or IE. Does Mozilla handle "file:" URL bookmarks specially? BTW, I also noticed that with Moz I have to give *five* slashes before the server name to make the URL work - NS 4.7x works fine with just two. Just my 2 cents. Ranjit.

marking confirmed based solely on ranjit's work to isolate the issue. ranjit, are you using any of the bookmark notification features at all?

No. The "Schedule" and "Notify" tabs in the "Properties" dialog don't even show up for "file://" URLs - they are shown only for "http" or "https" URLs. By extrapolation, though not by experimentation, this should also happen for mounted file systems (NFS,SMB,AFS, etc.) - hasn't anyone else faced this before? Or maybe not. I have noticed that most apps on Windoze *completely freeze* if they try to access a file on a server that the user has not yet logged on to. Ranjit

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged radar. You can filter out this email by looking for "ironstomachaussie"

mass reassign of pchen bookmark bugs to ben

Hi, Don't know if it really is related, but anyway. I'm using Mozilla 0.9.8, Gecko/20020208 on W2K. Next to it is a Linux box "dongen" running Samba, root filesystem shared as "root". When I try to access a file on the linux box from within Mozilla, I'd expect file://dongen/root/home/arthur/index.html to work. But to get it working I need to type file://///dongen/root/home/arthur/index.html (5 slashes). You know that Windows uses "\\dongen\root\home\arthur\index.html" in explorer. Netscape 4.79 accepts file:////dongen/root/home/arthur/index.html (four slashes). I expect Netscape to just peel off the "file://" part and pass the rest to the OS? Two slashes conforms to RFC 1738. Four slashes also sounds reasonable to me, at least under a Windows environment. But 5 is a bit overdone... :-\

This appears to be a dead-on duplicate of bug 70670. Because of the interesting test cases in this bug, though, I'll set it to depend on that bug.

I'm sorry, but I don't see how this is a "dead-on" duplicate of 70670. And now this has been marked "RESOLVED" because of the dependency on that bug. This problem is reproducible every time if you have bookmarked a file that resides on an NT server that you have to explicitly log on to (and you haven't). The URL takes on the form "file://..." for which *disabling date tracking* for the bookmark is not an option! A stat( ) or fstat( ) on such a file causes the calling thread to freeze on Windows for a considerable amount of time and it appears from this behaviour that Moz does UI rendering and date tracking in the same thread. BTW, as I have mentioned before, even Acrobat Reader (and some other software) behave like this if the list of recently accessed documents contains files that are on a server that has to be explicitly logged on to. There are two ways in which this can easily be resolved: 1. DO NOT assume that a "file://..." resource is always available (Therefore, at least provide the option of disabling date-tracking even for "file://..." bookmarks OR do not do it for "suspicious" URLs that start with five(!) slashes (incorporating the server name).) 2. Separate the UI rendering and date-tracking functions in different threads. Ranjit.

I'm sorry, but I don't see how this is a "dead-on" duplicate of 70670. And now this has been marked "RESOLVED" because of the dependency on that bug. This problem is reproducible every time if you have bookmarked a file that resides on an NT server that you have to explicitly log on to (and you haven't). The URL takes on the form "file://..." for which *disabling date tracking* for the bookmark is not an option! A stat( ) or fstat( ) on such a file causes the calling thread to freeze on Windows for a considerable amount of time and it appears from this behaviour that Moz does UI rendering and date tracking in the same thread. BTW, as I have mentioned before, even Acrobat Reader (and some other software) behave like this if the list of recently accessed documents contains files that are on a server that has to be explicitly logged on to. There are two ways in which this can easily be resolved: 1. DO NOT assume that a "file://..." resource is always available (Therefore, at least provide the option of disabling date-tracking even for "file://..." bookmarks OR do not do it for "suspicious" URLs that start with five(!) slashes (incorporating the server name).) 2. Separate the UI rendering and date-tracking functions in different threads. Ranjit.

*** This bug has been marked as a duplicate of 98682 ***