97096 - Mozilla freezes when bookmarks service tries to access a server you aren't logged into

Status: RESOLVED DUPLICATE of bug 98682

(SeaMonkey :: Bookmarks & History, defect, P5)

Description

[Ranjit Mathew]

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
([e-mail])

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).

Comment 1

[Ranjit Mathew]

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.

Comment 2

[Ranjit Mathew]

*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.

Comment 3

[Claudius Gayle]

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

Comment 4

[Ranjit Mathew]

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

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 6

[Paul Chen]

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"

Comment 7

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 8

[Arthur van Dongen]

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... :-\

Comment 9

[Andrew Hagen]

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.

Comment 10

[Ranjit Mathew]

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.

Comment 11

[Ranjit Mathew]

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.

Comment 12

[Matthias Versen [:Matti]]

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