Closed
Bug 22848
Opened 25 years ago
Closed 25 years ago
pointer "catches" at one point on the browser window
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gwalla, Assigned: trudelle)
Details
Running M12 for Win32 (no fullcircle) on Windows 95, I've found an intermittent
problem in which the mouse pointer seems to "catch" on a point on the mozilla
window. The pointer just doesn't move for a brief (but definitely noticeable)
period of time It seems to be the same point every time, somewhere about a
third up from the bottom and a little to the left of center (approx. 1/8 left
of center). I'd give the exact coords, but I really have no way of knowing.
This only happens with mozilla, so I'm pretty sure it's not my mouse at fault.
It only seems to happen when the pointer is a standard pointer (not the
hyperlink hand, not the text insert tool).
Unfortunately (for the bug reporter, fortunately for everyone else!) this only
happens sporadically and with no discernible pattern. But it happens just often
enough to be annoying.
The browser window My monitor is set to 800x600 resolution, 16bpp color depth,
75Hz v-freq. and 46.79KHz h-freq. Display Device: Plug and Play Monitor. Hope
that helps. I really hope someone can reproduce this, so I can be sure I'm not
losing my mind :^S
Comment 1•25 years ago
|
||
Hmmm, I can't reproduce on my win95 machine. If you can narrow down any more,
please try or we'll have to mark as worksforme.
Reporter | ||
Comment 2•25 years ago
|
||
I think I figured out why it seemed to be catching at a certain point. I
reflexively pull the mouse down after typing something in the location box and
pressing return. So the pointer just happens to end up in aprrox. the same place
every time I load a new page. It's probably something to do with the act of
trying to load a new document causing the cursor to lock up briefly.
My guess is that it happens when typing in a new URL and hitting enter while
another file is still loading. This might confuse mozilla. Just a hunch there
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Comment 3•25 years ago
|
||
Okay, I think this is just a by-product of the current architecture and it's
blocking of the UI while doing DNS look-ups.
I'm going to mark this as won't fix, because I don't think it is going to be
addressed, but cc:ing valeski to see if he has anything to say on the matter.
BTW, how fast if your machine? I don't notice this on my 350Mhz machine.
Comment 4•25 years ago
|
||
yea. probably a blocking dns issue. cc'ing gordon.
Reporter | ||
Comment 5•25 years ago
|
||
Why would DNS lookups block the UI? Aren't they in different threads?
Right, the DNS lookup is currently being done on a Socket Transport thread, not
the UI thread (at least the last time I checked). On some versions of Unix,
gethostbyname() blocks the entire process, but this problem is reported on
Windows. I'm surprised calling gethostbyname() would freeze the cursor!
Reporter | ||
Comment 7•25 years ago
|
||
I'm going to see if I can nail down a repeatable test. If and when I do, I'll
officially reopen this.
Assignee | ||
Comment 8•25 years ago
|
||
Don't think this is blocked UI. Isn't the mouse pointer still tracked and drawn
by the system at interrupt time, on all platforms?
Reporter | ||
Comment 9•25 years ago
|
||
That's what I thought. I really couldn't tell you what might be causing this in
the code, just that it happened.
May have to wait a bit for that test. I've been moved to a different machine and
my new one has a completely unrelated problem (Bug #19165). Leaving this as
"RESOLVED" for the time being.
Reporter | ||
Comment 10•25 years ago
|
||
I haven't been able to reproduce this on any other machine. I suppose it must
have had something to do with a quirk on that particular computer.
You need to log in
before you can comment on or make changes to this bug.
Description
•