Closed Bug 198345 Opened 23 years ago Closed 22 years ago

Freezes at times when attempting to type in the url or when accessing a page through bookmarks.

Categories

(SeaMonkey :: Find In Page, defect)

Product:
SeaMonkey
Component:
Find In Page
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 230585

People

(Reporter: usedtobeahero, Assigned: aaronlev)

References

Details

(Keywords: hang, helpwanted, qawanted)

User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3; MultiZilla v1.3.1.2) Gecko/20030312 Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3; MultiZilla v1.3.1.2) Gecko/20030312 Mozilla freezes when attempting to type in a url or in the case of accessing a page through the bookmarks it freezes midway through the process... Repeated restarts of the browser seem to solve the problem and it affects Mozilla while running in both the Root and normal user mode. There is a slight flicker in the Stop button just before the browser freezes. Also, at times, while typing a url, it does not freeze completely but seems to hang for a couple of seconds. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3.
The problem seems to be with the Find as you Type feature. Disabling it seems to get rid of the problem. Manually starting the feature at times resulted in Mozilla freezing.
> The problem seems to be with the Find as you Type feature. are you saying that Find-as-you-Type makes loading pages from bookmarks freeze up? is it ever a permanent hang or always just temporary (a couple seconds)
I think I should explain the entire thing again: With Find as you Type automatically enabled, the browser does either of three things: 1. Hangs; i.e. I have to manually kill it. This happens when I attempt to type in the URL or midway through accessing a page if I don't use the URL bar and use the bookmarks instead. 2. Hangs for a few seconds and then is back to normal. 3. Works absolutely normally. When it does hang, repeated restarts (of the browser) are needed, as much as six or seven before the browser functions again. With Find as you Type disabled, everything works fine, but when manually starting Find as you Type with the / key it *sometimes* freezes. I hope this is much more clearer.
==> find as you type
Assignee: asa → aaronl
Component: Browser-General → Keyboard: Find as you Type
Keywords: hang
QA Contact: asa → sairuh
*** Bug 199599 has been marked as a duplicate of this bug. ***
I found this bug does not happen if I boot mozilla and type in the location bar BEFORE I connect to the internet( using wvdial ) HTH Steve ------------------------------- My Platform -------------------------------- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 I am using mozilla 1.3 with Knoppix 3.2 (4/15/03 build - sub distro of debian).
*** Bug 202775 has been marked as a duplicate of this bug. ***
confirming based on multiple independent reports
Status: UNCONFIRMED → NEW
Ever confirmed: true
i'm (so far) unable to reproduce this hang (using 2003.04.18.08 build on linux rh7.2), with find as you type set to autofind when typing. could you please provide a specific set of steps to get into this state? are you referring to the bookmarks manager window, or the bookmarks menu? where is focus (the cursor or caret) when this occurs?
Keywords: qawanted
*** Bug 204705 has been marked as a duplicate of this bug. ***
i have the same problem in mozilla 1.4xxx, Mozilla works okay until i start typing somewhere, ie. URL or "creat folder", etc. at that point mozilla freezes solidly at the first input keystroke. I am running a completly updated redhat 7.3 on athlon 2000xp. It fails for all recent Mozilla(s) i have tried downloading or building. Netscape 7.02 & Mozilla 1.0x work fine !!!
are the people here using KDE and audiofile? see bug 210209
No. I normally use Window Maker. I think I tried it for a while in Gnome too. Same result.
hi Lucky Pozzo, how about audiofile? do you use audiofile? Andrew, thanks for the sharp eye and pointing out bug #21029 as well; incidentally, the bug report is about audiofile in particular, and not really kde. Lucky Pozzo, if you could, try the "fix" mentioned in bug #21029 and see what happens? this would help to verify things. Thanks.
Jeffrey, I tried uninstalling audiofile immediately after reading about the other bug but, unfortunately, there were too many dependencies... The only time audiofile's active on my system is when I get a mail alert - I use ESD for that. Anyway, I'll experiment a bit with Gnome and ESD and let everybody know if I come up with anything.
I just remembered: When I first posted this bug I was using KMail, which starts off all these KDE server processes. I've since stopped using KMail and I restarted Mozilla about 12 times right now with "Find as you Type" enabled and ESD on, and everything's working perfectly. Since I no longer have KDE installed I can't say for sure if that's what's caused the bug, but it does seem like it. Perhaps it's a KDE-arts problem, since ESD doesn't seem to affect Mozilla.
Firstly, I wish to apologize for my rather hasty post earlier. The bug's struck again. I went through the entire restart process again after posting. And just when I was on the verge of believing that KMail had been the problem, it happened again. I tried a whole bunch of things - random keystrokes, random mouse clicks, enabling and disabling the various options - "links only" "no sound" etc etc, but it seems to be entirely arbitrary. Once again, apologies all around.
It's still there in 1.4
I first discovered this bug today (Mozilla 1.4, Linux i386), after upgrading my CPU, motherboard and RAM. I know it sounds strange, but find-as-you-type worked fine while I was using my old system: CPU: Athlon T-Bird 1.4 GHz Motherboard: ABIT KG7 RAID (AMD 761 chipset) Memory: 256 MB SDRAM New system: CPU: Athlon XP 2500+ Motherboard: MSI K7N2 Delta ILSR (NVIDIA nForce2 chipset) Memory: 512 MB DDR SDRAM If the new hardware is to blame, my first guess is the new motherboard. This wouldn't be the first NVIDIA-related bug in Mozilla.
bug 213286 was another instance of bug 210209 (sound initialization causes the hang), but with esd instead of audiofile. so just because you don't use/have audiofile doesn't mean you can't see bug 210209. a stacktrace (from gdb) here would be helpful
I'm using Red Hat 9.0 and the mozilla 1.4 rpm and it was working very well. Since I updated some packages (almost all) from the redhat linux errata website I experienced this hangs when I press anything on the keyboard. (I am not sure that upgrading the packages caused it) I installed mozilla 1.5a and the same. Disabling the type ahead feature solved the problem.
*** Bug 227094 has been marked as a duplicate of this bug. ***
*** Bug 215216 has been marked as a duplicate of this bug. ***
*** Bug 210894 has been marked as a duplicate of this bug. ***
*** Bug 198862 has been marked as a duplicate of this bug. ***
It is iptables or /etc/hosts Take a look at the gentoo forum http://forums.gentoo.org/viewtopic.php?t=129496 I did on my PC a very stupid mistake. I wrote 128.0.0.1 instead 127.0.0.1 in /etc/hosts. Now is everything okay! It is not a mozilla bug! Nelvin
*** Bug 200795 has been marked as a duplicate of this bug. ***
I see the same behaviour with 1.7b (RC1?) Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 I either type in a URL in the location bar and hit enter or try to access a bookmark, and nothing happens. Mozilla is still responsive, I can open new tabs (in which my default homepage shows up), I can still (at least) browse the menus. One indicator of this blockage is that find-as-you-type does not work anymore in these situations. Once, the browser, already being unable to load new pages, froze completely when I hit the submit button on a webpage, with the confirmation dialogue box in front. Restarting fixes it, until it strikes again.
Problem still there with Mozilla 1.7RC2 (Mac OS X 10.3.3). Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 Could be the same as bug 227528.
> Could be the same as bug 227528. Not the same problem, as mentioned in that bug.
How are people accessing the bookmarks when this happens? [ ] the personal toolbar [ ] the sidebar [ ] the bookmarks menu All of the above? Some of the above? I can't fix this without some kind of better testcase.
Blocks: atfmeta
QA Contact: bugzilla → jessie.li
(In reply to comment #30) > > Could be the same as bug 227528. > > Not the same problem, as mentioned in that bug. I thought it could be same since I've seen these things happen in sequence several times. In the sense that once Mozilla doesn't accept URLs or bookmarks anymore, i.e. this bug has struck, and I open let's say the preferences window, clicking o.k. there doesn't do anything anymore, i.e bug 227528.
(In reply to comment #31) > How are people accessing the bookmarks when this happens? > > [ ] the personal toolbar > [ ] the sidebar > [ ] the bookmarks menu > > All of the above? Some of the above? > > I can't fix this without some kind of better testcase. In my case (Mozilla 1.7 RC2 and earlier versions Mac OS X 10.3.4) I was using the bookmarks menu.
With all the reassignments I may not be talking about the same bug anymore. In my case (RH7.2 out-of-the-box, mozilla 1.7b NO KDE, no (known) audiofile involvements, default desktop, with find-as-you-type enabled, the first character I type ANYWHERE, under ANY CIRCUMSTANCE (ie, into some setup window, into a URL, ANYPLACE) it instantly and irreversibly hangs. With find-as-you-type disabled, there is no problem. I hope this is of some use.
Jim, do you build Mozilla yourself? If so, can you use gdb or something to find out where it hangs? I guess this is helpwanted unless I can get a reproducable test case for myself. Otherwise, I think someone from the community who's experiencing this bug should step forward and help determine where in the code it's looping. - Aaron (In reply to comment #34) > With all the reassignments I may not be talking about the same bug anymore. > In my case (RH7.2 out-of-the-box, mozilla 1.7b NO KDE, no (known) audiofile > involvements, default desktop, with find-as-you-type enabled, the first > character I type ANYWHERE, under ANY CIRCUMSTANCE (ie, into some setup window, > into a URL, ANYPLACE) it instantly and irreversibly hangs. With > find-as-you-type disabled, there is no problem. > I hope this is of some use.
Keywords: helpwanted
I have exactly the same problem as Jim, and have strace'd it, and that show's it hangs after it's trying to connect to port 16001 on localhost. (what seems to be the port esd/esound is normally listening to (i don't have esound installed, so maybe mozilla shouldn't try to connect to it?)) So I checked my interfaces and lo was down (it's not upped by the fresh installed ifplugd) so it seems to be about the same as with Nelvin. After bringing lo up there are no problems. It's reproducible: ifdown lo mozilla type ahead find (/ or automatic) After about a few minutes after reproducing the freeze it's running again, i thought that wasn't the case when i first encountered this bug, but maybe i'm wrong and was too impatient then. After the first freeze there are no other freezes. I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 here's the end of the strace: gettimeofday({1087035835, 246657}, NULL) = 0 gettimeofday({1087035835, 246693}, NULL) = 0 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=12, events=POLLIN| POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN}], 7, 0) = 0 ioctl(3, FIONREAD, [0]) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}, {fd=8, events=POLLIN}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN| POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN}, {fd=4, events=POLLIN}], 8, -1) = 1 ioctl(3, FIONREAD, [32]) = 0 read(3, "\2&\16\10\333\10U\0\263\0\0\0.\0`\1\0\0\0\0U\1}\1T\1h\1"..., 32) = 32 write(3, "\227\10\7\0\0\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 28) = 28 read(3, "\1\4\17\10\t\3\0\0\0\0\10\377\3\0\0\f\f\10\301\0\370\0"..., 32) = 32 read(3, "\0\0\0\0\0\0\0\0", 8) = 8 read(3, "\0\0\0\0\1\0\0\277\1\1\0\0\2\1\0\10\1\1\1\1\0\0\0\0\3\3"..., 3100) = 3100 write(3, "\227\21\3\0\4\0\3\0\0\20\0\0", 12) = 12 read(3, "\1\4\20\10\1\0\0\0\0\20\0\0\10\377\f\1\0\0\10\370\0\0\0"..., 32) = 32 read(3, "\220\0\0\0", 4) = 4 gettimeofday({1087035835, 872781}, NULL) = 0 stat64("/usr/lib/mozilla/res/builtin/userHTMLBindings.xml", 0xbfffc26c) = -1 ENOENT (No such file or directory) lstat64("/usr/lib/mozilla/res/builtin/userHTMLBindings.xml", 0xbfffc26c) = -1 ENOENT (No such file or directory) gettimeofday({1087035835, 875804}, NULL) = 0 uname({sys="Linux", node="herry", ...}) = 0 access("/tmp/.esd/socket", R_OK|W_OK) = -1 ENOENT (No such file or directory) socket(PF_UNIX, SOCK_STREAM, 0) = 37 connect(37, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) close(37) = 0 open("/etc/hosts", O_RDONLY) = 37 fcntl64(37, F_GETFD) = 0 fcntl64(37, F_SETFD, FD_CLOEXEC) = 0 fstat64(37, {st_mode=S_IFREG|0644, st_size=275, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x434a7000 read(37, "127.0.0.1\therry\tlocalhost\n\n# The"..., 4096) = 275 read(37, "", 4096) = 0 close(37) = 0 munmap(0x434a7000, 4096) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 37 fcntl64(37, F_SETFD, FD_CLOEXEC) = 0 setsockopt(37, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 connect(37, {sa_family=AF_INET, sin_port=htons(16001), sin_addr=inet_addr("127.0.0.1")}, 16
the loopback interface is generally a required element of any Linux OS. http://www.linuxforum.com/linux-network-admin/node66.html > However, the loopback interface is useful not only as an example in networking > books, or as a test-bed during development, but is actually used by some > applications during normal operation. (For instance, all applications based on > RPC use the loopback interface to register themselves with the portmapper daemon > at startup.) Therefore, you always have to configure it, regardless of whether > your machine is attached to a network or not.
If you turn accessibility.typeaheadfind to true (turn it back on again) but turn off the soundby setting accessibility.typeaheadfind.enablesound to false does it still hang? The settings can be changed in about:config or Edit -> Preferences -> Advanced -> Keyboard I'll look in more details at the new comments later. In the mean time, his is sounding like a dup of bug 230585. Can someone look into it? There is also bug 110385, I don't know if it relates. I'm no sound or linux expert. Perhaps we should disable the find as you type sound in Linux by default. In fact, I thought someone had already made that change, but I guess not.
See bug 191580 which was fixed in early February. If your typeaheadfind sound is set to "beep", which it is by default on Linux, then you shouldn't have a problem in recent builds.
When i disable the sound there are no problems. When i enable sound with accessibility.typeaheadfind.soundURL=beep there is no sound, but mozilla tries to connect 16001 (maybe the patch of bug 191580 isn't applied on the debian build 20040413) When i enable sound with accessibility.typeaheadfind.soundURL=default it plays the default sound on esd when i enter an url in accessibility.typeaheadfind.soundURL of a wavefile it plays nothing, but tries to connect to 16001 (that's another bug or just my fault i guess, i used the same url that works for new email sound) it did play the default sound before i installed esound, so esound isn't neccesary, but if i disable esound now it won't play (even after restarting mozilla) This bug isn't really bad i think, as localhost should be accessible, only the timeout of a few minutes is a bit long
I'm pretty sure this is a DUP now. Thanks to everyone who helped track it down to a sound problem. *** This bug has been marked as a duplicate of 230585 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.