Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.apps > #21064 > unrolled thread

pointer can't penetrate link area

Back to article view | Back to comp.sys.mac.apps

Contents

  pointer can't penetrate link area Dushan Mitrovich <dushanm@nnips.net> - 2014-02-10 17:15 -0700
    Re: pointer can't penetrate link area philo  <philo@privacy.net> - 2014-02-10 18:21 -0600
      Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-11 12:18 -0700
        Re: pointer can't penetrate link area philo  <philo@privacy.net> - 2014-02-11 16:20 -0600
          Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-13 19:29 -0700
            Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-17 17:24 -0700
              Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-02-18 00:59 +0000
                Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-18 00:10 -0700
                  Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-02-18 16:44 +0000
                    Re: pointer can't penetrate link area Barry Margolin <barmar@alum.mit.edu> - 2014-02-18 12:31 -0500
                      Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-02-18 19:25 +0000
                    Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-22 00:48 -0700
                      Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-02-22 16:00 +0000
                        Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-24 19:45 -0700
                          Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-28 12:21 -0700
                            Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-03-06 16:01 -0700
                              Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-03-07 01:01 +0000
                                Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-03-08 14:50 -0700
                                  Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-03-08 22:32 +0000
                                    Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-03-10 18:45 -0600
                                      Re: pointer can't penetrate link area Jolly Roger <jollyroger@pobox.com> - 2014-03-11 01:19 +0000
                                        Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-03-18 14:12 -0600
                                        Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-03-18 14:12 -0600
                                          Re: pointer can't penetrate link area - SOLVED dushanm@nnips.net (DushanM) - 2014-03-21 21:58 -0600
                                            Re: pointer can't penetrate link area - SOLVED Jolly Roger <jollyroger@pobox.com> - 2014-03-22 18:28 +0000
                                              Re: pointer can't penetrate link area - UNSOLVED dushanm@nnips.net (DushanM) - 2014-03-24 20:35 -0600
                                                Re: pointer can't penetrate link area - RE-SOLVED dushanm@nnips.net (DushanM) - 2014-04-03 13:37 -0600
                                                  Re: pointer can't penetrate link area - RE-SOLVED Jolly Roger <jollyroger@pobox.com> - 2014-04-03 21:10 +0000
                                                    Re: pointer can't penetrate link area - RE-SOLVED dushanm@nnips.net (DushanM) - 2014-04-09 16:09 -0600
                  Re: pointer can't penetrate link area dushanm@nnips.net (DushanM) - 2014-02-22 00:47 -0700
    Re: pointer can't penetrate link area dorayme <do_ray_me@bigpond.com> - 2014-02-11 11:29 +1100

Page 1 of 2  [1] 2  Next page →

#21064 — pointer can't penetrate link area

On our iMac running Mountain Lion X.8.5 we have two accounts, my wife's 
and mine.  Using the Firefox browser on my wife's account, the pointer 
moves around the screen as expected with either the Magic Mouse or the 
Logitech trackball.

Starting several weeks ago, wherever the pointer encounters a link the 
pointer turns into a pointing hand and is unable to move further into 
the screen area occupied by the link.  It came move parallel with the 
area boundary, and it can invisibly traverse the area to reappear as a 
pointer on the other side, but it doesn't move within the link area 
(though the link itself still works).

This occurs with both the M.Mouse and the trackball, but it only occurs 
on my wife's account and not on mine (I also use Firefox).  I've read of 
other people having similar issues the past couple of years, but didn't 
notice a fix, nor a positive identification of the cause of this behavior.

Has anyone here run across this peculiarity, and have some suggestions?

Thanks.

- Dushan
   [ reverse the middle word of address to reply ]

[toc] | [next] | [standalone]

#21066

On 02/10/2014 06:15 PM, Dushan Mitrovich wrote:
> On our iMac running Mountain Lion X.8.5 we have two accounts, my wife's
> and mine.  Using the Firefox browser on my wife's account, the pointer
> moves around the screen as expected with either the Magic Mouse or the
> Logitech trackball.
>
> Starting several weeks ago, wherever the pointer encounters a link the
> pointer turns into a pointing hand and is unable to move further into
> the screen area occupied by the link.  It came move parallel with the
> area boundary, and it can invisibly traverse the area to reappear as a
> pointer on the other side, but it doesn't move within the link area
> (though the link itself still works).
>
> This occurs with both the M.Mouse and the trackball, but it only occurs
> on my wife's account and not on mine (I also use Firefox).  I've read of
> other people having similar issues the past couple of years, but didn't
> notice a fix, nor a positive identification of the cause of this behavior.
>
> Has anyone here run across this peculiarity, and have some suggestions?
>
> Thanks.
>
>X


You posted the same question a few weeks ago, got a reply and ignored it.

If I understand you other post correctly, the problem began the instant 
you upgraded to 8.5 from 8.4?

[toc] | [prev] | [next] | [standalone]

#21077

philo  <philo@privacy.net> wrote:

> On 02/10/2014 06:15 PM, Dushan Mitrovich wrote:
> > On our iMac running Mountain Lion X.8.5 we have two accounts, my wife's
> > and mine.  Using the Firefox browser on my wife's account, the pointer
> > moves around the screen as expected with either the Magic Mouse or the
> > Logitech trackball.
> >
> > Starting several weeks ago, wherever the pointer encounters a link the
> > pointer turns into a pointing hand and is unable to move further into
> > the screen area occupied by the link.  It came move parallel with the
> > area boundary, and it can invisibly traverse the area to reappear as a
> > pointer on the other side, but it doesn't move within the link area
> > (though the link itself still works).
> >
> > This occurs with both the M.Mouse and the trackball, but it only occurs
> > on my wife's account and not on mine (I also use Firefox).  I've read of
> > other people having similar issues the past couple of years, but didn't
> > notice a fix, nor a positive identification of the cause of this behavior.
> >
> > Has anyone here run across this peculiarity, and have some suggestions?
> >
> > Thanks.
> >
> >X
> 
> 
> You posted the same question a few weeks ago, got a reply and ignored it.
> 
> If I understand you other post correctly, the problem began the instant
> you upgraded to 8.5 from 8.4?

philo,

First, an apology: I didn't intentionally ignore the ealier reply.  I
didn't know it existed - after looking at Google Groups for this forum I
could find no trace of my original question, let alone a reply.  I had
posted the question from the iMac, which doesn't have a newsreader.  In
any case I thought the question never reached the forum; hence the
repeat.  Now, from my office Mac, I'll look for the earlier reply.

I'm not sure the problem started exactly when the upgrade occurred.
This is especially questionable since it only occurs on one account and
not the other, even though they are under the very same OS.  Maybe it's
possible.

- Dushan

PS: in answer to dorayme:
    Yes, it happens on all links on all web pages.

[toc] | [prev] | [next] | [standalone]

#21079

On 02/11/2014 01:18 PM, DushanM wrote:


<snip>

OK


Here is the reply you got
  from Michael V.



What's the site's URL. I don't use wireless devices unless I'm reading a
lot of stuff. I've never seen a pointer freeze when mousing over a URL
UNLESS it's doing something bad like running a poorly written
Javascript.  You should be able to COMMAND-TAB to another application
like the Finder and run Activity Monitor to show what's going on.

Alternately, run XRG then go to your site

https://www.macupdate.com/app/mac/10220/xrg

You should see the browser eating up all the CPU.  That tells me there's
rogue Javascript.  If this is in an application, then there's a possible
problem with Magic Mouse.  Switch to a wired mouse and see what happens.
They're cheap on Amazon. I always have wired devices for backups because
batteries die and I may not have a replacement.

<http://www.amazon.com/Macally-Button-Optical-BUMPER-MOUSE/dp/B00EQ94566>
<http://www.amazon.com/Belkin-Button-Optical-Desktop-Netbook/dp/B007CLWN5
A>
<http://www.amazon.com/Kensington-K72356US-Mouse-Desktop-Mouse/dp/B002ZIN
9DU>

[toc] | [prev] | [next] | [standalone]

#21104

philo, thanks for showing me that older msg.  I'll check things out with
both the Activity Monitor and XRG, and report back.

- Dushan
 

philo  <philo@privacy.net> wrote:

> On 02/11/2014 01:18 PM, DushanM wrote:
> 
> 
> <snip>
> 
> OK
> 
> 
> Here is the reply you got
>   from Michael V.
> 
> 
> 
> What's the site's URL. I don't use wireless devices unless I'm reading a
> lot of stuff. I've never seen a pointer freeze when mousing over a URL
> UNLESS it's doing something bad like running a poorly written
> Javascript.  You should be able to COMMAND-TAB to another application
> like the Finder and run Activity Monitor to show what's going on.
> 
> Alternately, run XRG then go to your site
> 
> https://www.macupdate.com/app/mac/10220/xrg
> 
> You should see the browser eating up all the CPU.  That tells me there's
> rogue Javascript.  If this is in an application, then there's a possible
> problem with Magic Mouse.  Switch to a wired mouse and see what happens.
> They're cheap on Amazon. I always have wired devices for backups because
> batteries die and I may not have a replacement.
> 
> <http://www.amazon.com/Macally-Button-Optical-BUMPER-MOUSE/dp/B00EQ94566>
> <http://www.amazon.com/Belkin-Button-Optical-Desktop-Netbook/dp/B007CLWN5
> A>
> <http://www.amazon.com/Kensington-K72356US-Mouse-Desktop-Mouse/dp/B002ZIN
> 9DU>

[toc] | [prev] | [next] | [standalone]

#21131

As suggested, I explored the CPU changes when the pointer freeze occurs.
Here is a compilation of observations:

# I ran both the Activity Monitor and XRG, and neither report a change
  in CPU usage level for the browser when the pointer has turned into a
  frozen pointing hand, as opposed to when it is a freely moving pointer

# the problem happens for _every_ link that causes the pointer to turn
  into a pointing hand, whose depiction is frozen until the pointer
  location moves out from the screen area allocated to the link 

# it happens for both the Magic Mouse and the Logitech trackball

# it is independent of the browser used; I tried Firefox, Safari,
  Roccat, and chromium

# it only happens on one account, but not the other

# the problem didn't exist until about two months ago

Can anyone suggest any other tests I can run?

- Dushan


DushanM <dushanm@nnips.net> wrote:

> philo, thanks for showing me that older msg.  I'll check things out with
> both the Activity Monitor and XRG, and report back.
> 
> - Dushan
>  
> 
> philo  <philo@privacy.net> wrote:
> 
> > On 02/11/2014 01:18 PM, DushanM wrote:
> > 
> > 
> > <snip>
> > 
> > OK
> > 
> > 
> > Here is the reply you got
> >   from Michael V.
> > 
> > 
> > 
> > What's the site's URL. I don't use wireless devices unless I'm reading a
> > lot of stuff. I've never seen a pointer freeze when mousing over a URL
> > UNLESS it's doing something bad like running a poorly written
> > Javascript.  You should be able to COMMAND-TAB to another application
> > like the Finder and run Activity Monitor to show what's going on.
> > 
> > Alternately, run XRG then go to your site
> > 
> > https://www.macupdate.com/app/mac/10220/xrg
> > 
> > You should see the browser eating up all the CPU.  That tells me there's
> > rogue Javascript.  If this is in an application, then there's a possible
> > problem with Magic Mouse.  Switch to a wired mouse and see what happens.
> > They're cheap on Amazon. I always have wired devices for backups because
> > batteries die and I may not have a replacement.
> > 
> > <http://www.amazon.com/Macally-Button-Optical-BUMPER-MOUSE/dp/B00EQ94566>
> > <http://www.amazon.com/Belkin-Button-Optical-Desktop-Netbook/dp/B007CLWN5
> > A>
> > <http://www.amazon.com/Kensington-K72356US-Mouse-Desktop-Mouse/dp/B002ZIN
> > 9DU>

[toc] | [prev] | [next] | [standalone]

#21132

On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
> As suggested, I explored the CPU changes when the pointer freeze occurs.
> Here is a compilation of observations:
>
> # I ran both the Activity Monitor and XRG, and neither report a change
>   in CPU usage level for the browser when the pointer has turned into a
>   frozen pointing hand, as opposed to when it is a freely moving pointer
>
> # the problem happens for _every_ link that causes the pointer to turn
>   into a pointing hand, whose depiction is frozen until the pointer
>   location moves out from the screen area allocated to the link 
>
> # it happens for both the Magic Mouse and the Logitech trackball
>
> # it is independent of the browser used; I tried Firefox, Safari,
>   Roccat, and chromium
>
> # it only happens on one account, but not the other
>
> # the problem didn't exist until about two months ago
>
> Can anyone suggest any other tests I can run?

I would be interested to know if anything at all is logged to the
console or system logs when the pointer changes to the hand. Open
/Applications/Utilities/Console and watch it while you do a test. Report
results here.

The fact that this happens only in one account is good - it means it's
not a system-wide issue, and likely has something to do with a
preference file or cache file in your user account.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21134

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
> > As suggested, I explored the CPU changes when the pointer freeze occurs.
> > Here is a compilation of observations:
> >
> > # I ran both the Activity Monitor and XRG, and neither report a change
> >   in CPU usage level for the browser when the pointer has turned into a
> >   frozen pointing hand, as opposed to when it is a freely moving pointer
> >
> > # the problem happens for _every_ link that causes the pointer to turn
> >   into a pointing hand, whose depiction is frozen until the pointer
> >   location moves out from the screen area allocated to the link 
> >
> > # it happens for both the Magic Mouse and the Logitech trackball
> >
> > # it is independent of the browser used; I tried Firefox, Safari,
> >   Roccat, and chromium
> >
> > # it only happens on one account, but not the other
> >
> > # the problem didn't exist until about two months ago
> >
> > Can anyone suggest any other tests I can run?
> 
> I would be interested to know if anything at all is logged to the
> console or system logs when the pointer changes to the hand. Open
> /Applications/Utilities/Console and watch it while you do a test. Report
> results here.
> 
> The fact that this happens only in one account is good - it means it's
> not a system-wide issue, and likely has something to do with a
> preference file or cache file in your user account.

I may not get to check on that until the w.e. as I'm away from the iMac
'til then.  But when I get to it I'll check the Console.

- Dushan

[toc] | [prev] | [next] | [standalone]

#21138

On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
> Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
>> > As suggested, I explored the CPU changes when the pointer freeze occurs.
>> > Here is a compilation of observations:
>> >
>> > # I ran both the Activity Monitor and XRG, and neither report a change
>> >   in CPU usage level for the browser when the pointer has turned into a
>> >   frozen pointing hand, as opposed to when it is a freely moving pointer
>> >
>> > # the problem happens for _every_ link that causes the pointer to turn
>> >   into a pointing hand, whose depiction is frozen until the pointer
>> >   location moves out from the screen area allocated to the link 
>> >
>> > # it happens for both the Magic Mouse and the Logitech trackball
>> >
>> > # it is independent of the browser used; I tried Firefox, Safari,
>> >   Roccat, and chromium
>> >
>> > # it only happens on one account, but not the other
>> >
>> > # the problem didn't exist until about two months ago
>> >
>> > Can anyone suggest any other tests I can run?
>> 
>> I would be interested to know if anything at all is logged to the
>> console or system logs when the pointer changes to the hand. Open
>> /Applications/Utilities/Console and watch it while you do a test. Report
>> results here.
>> 
>> The fact that this happens only in one account is good - it means it's
>> not a system-wide issue, and likely has something to do with a
>> preference file or cache file in your user account.
>
> I may not get to check on that until the w.e. as I'm away from the iMac
> 'til then.  But when I get to it I'll check the Console.

After you monitor the logs, another thing you could try is deleting all
cache files. There are many utilities that can do this for you. One of
them is Cocktail <https://www.macupdate.com/app/mac/10909/cocktail>. Run
Cocktail, click the Files tab at the top of the window, check each of
the check boxes (System, User, Internet) under the current user column,
and then click the Clear button. Then restart your computer and see if
the issue persists. This will tell you whether the problem is a cache
file. (Note that Cocktail can also be configured to delete even more
cache files than it does by default. See the Options button for
details.)

After that, another thing you could try is logging out of the problem
account, using an administrator account to move the contents of the
problem user's ~/Library/Preferences folder to a temporary location
(leaving the ~/Library/Preferences folder empty), and then logging back
into the problem account to see if the problem is resolved. This would
tell you whether the problem file is in the preferences folder.

Do try looking at the logs first. They may give you a clue as to
exactly where the problem lies without having to mess with cache and
preferences files.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21139

In article <bmhgv1FbhmfU1@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> After you monitor the logs, another thing you could try is deleting all
> cache files. There are many utilities that can do this for you.

He said this affects multiple browsers and all web sites. Each browser 
has its own cache files, I don't see how they all could be corrupted in 
the same way.

This seems like it must be some kind of systemic problem, although I'm 
not sure what it would be.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#21140

On 2014-02-18, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <bmhgv1FbhmfU1@mid.individual.net>,
>  Jolly Roger <jollyroger@pobox.com> wrote:
>
>> After you monitor the logs, another thing you could try is deleting all
>> cache files. There are many utilities that can do this for you.
>
> He said this affects multiple browsers and all web sites. Each browser 
> has its own cache files, I don't see how they all could be corrupted in 
> the same way.
>
> This seems like it must be some kind of systemic problem, although I'm 
> not sure what it would be.

No, Mac OS X uses cache files for many, many more things than just web
browsers. It could very well be that a cache file unrelated to web
browsers is causing unwanted behavior - in fact I have seen it many
times myself. Utilities like Cocktail delete web browser caches as well
as other Mac OS X cache files. And deleting these cache files is
relatively harmless, since they will subsequently be rebuilt
automatically. 

So my suggestion stands. Removing cache files (and letting the OS
rebuild them after a restart) is worth trying, and may solve the problem
for the OP.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21159

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
> > Jolly Roger <jollyroger@pobox.com> wrote:
> >
> >> On 2014-02-18, DushanM <dushanm@nnips.net> wrote:
> >> > As suggested, I explored the CPU changes when the pointer freeze occurs.
> >> > Here is a compilation of observations:
> >> >
> >> > # I ran both the Activity Monitor and XRG, and neither report a change
> >> >   in CPU usage level for the browser when the pointer has turned into a
> >> >   frozen pointing hand, as opposed to when it is a freely moving pointer
> >> >
> >> > # the problem happens for _every_ link that causes the pointer to turn
> >> >   into a pointing hand, whose depiction is frozen until the pointer
> >> >   location moves out from the screen area allocated to the link 
> >> >
> >> > # it happens for both the Magic Mouse and the Logitech trackball
> >> >
> >> > # it is independent of the browser used; I tried Firefox, Safari,
> >> >   Roccat, and chromium
> >> >
> >> > # it only happens on one account, but not the other
> >> >
> >> > # the problem didn't exist until about two months ago
> >> >
> >> > Can anyone suggest any other tests I can run?
> >> 
> >> I would be interested to know if anything at all is logged to the
> >> console or system logs when the pointer changes to the hand. Open
> >> /Applications/Utilities/Console and watch it while you do a test. Report
> >> results here.
> >> 
> >> The fact that this happens only in one account is good - it means it's
> >> not a system-wide issue, and likely has something to do with a
> >> preference file or cache file in your user account.
> >
> > I may not get to check on that until the w.e. as I'm away from the iMac
> > 'til then.  But when I get to it I'll check the Console.
> 
> After you monitor the logs, another thing you could try is deleting all
> cache files. There are many utilities that can do this for you. One of
> them is Cocktail <https://www.macupdate.com/app/mac/10909/cocktail>. Run
> Cocktail, click the Files tab at the top of the window, check each of
> the check boxes (System, User, Internet) under the current user column,
> and then click the Clear button. Then restart your computer and see if
> the issue persists. This will tell you whether the problem is a cache
> file. (Note that Cocktail can also be configured to delete even more
> cache files than it does by default. See the Options button for
> details.)
> 
> After that, another thing you could try is logging out of the problem
> account, using an administrator account to move the contents of the
> problem user's ~/Library/Preferences folder to a temporary location
> (leaving the ~/Library/Preferences folder empty), and then logging back
> into the problem account to see if the problem is resolved. This would
> tell you whether the problem file is in the preferences folder.
> 
> Do try looking at the logs first. They may give you a clue as to
> exactly where the problem lies without having to mess with cache and
> preferences files.

Clearing the cache worked!

First I did look at the log file in Console, and that showed absolutely
no new message when the pointer comes up against a link.  So following
your suggestion I downloaded Cocktail and deleted first all the Internet
cache files.  That made no difference.  Then I went back into Cocktail
and deleted the User cache files (I was trying to narrow it down a bit),
and restarted.  Now the pointer could move everywhere, as pointing hand
or just arrow.

Thank you much for that suggestion.  I'm still wondering, tho, how that
particular glitch got there to begin with.  At least now I know how to
fix a recurrance.  Looks like Cocktail is a useful program.

- Dushan

[toc] | [prev] | [next] | [standalone]

#21161

On 2014-02-22, DushanM <dushanm@nnips.net> wrote:
> Jolly Roger <jollyroger@pobox.com> wrote:
>> 
>> After you monitor the logs, another thing you could try is deleting all
>> cache files. There are many utilities that can do this for you. One of
>> them is Cocktail <https://www.macupdate.com/app/mac/10909/cocktail>. Run
>> Cocktail, click the Files tab at the top of the window, check each of
>> the check boxes (System, User, Internet) under the current user column,
>> and then click the Clear button. Then restart your computer and see if
>> the issue persists. This will tell you whether the problem is a cache
>> file. (Note that Cocktail can also be configured to delete even more
>> cache files than it does by default. See the Options button for
>> details.)
>> 
>> After that, another thing you could try is logging out of the problem
>> account, using an administrator account to move the contents of the
>> problem user's ~/Library/Preferences folder to a temporary location
>> (leaving the ~/Library/Preferences folder empty), and then logging back
>> into the problem account to see if the problem is resolved. This would
>> tell you whether the problem file is in the preferences folder.
>> 
>> Do try looking at the logs first. They may give you a clue as to
>> exactly where the problem lies without having to mess with cache and
>> preferences files.
>
> Clearing the cache worked!
>
> First I did look at the log file in Console, and that showed absolutely
> no new message when the pointer comes up against a link.  So following
> your suggestion I downloaded Cocktail and deleted first all the Internet
> cache files.  That made no difference.  Then I went back into Cocktail
> and deleted the User cache files (I was trying to narrow it down a bit),
> and restarted.  Now the pointer could move everywhere, as pointing hand
> or just arrow.
>
> Thank you much for that suggestion.  I'm still wondering, tho, how that
> particular glitch got there to begin with.  At least now I know how to
> fix a recurrance.  Looks like Cocktail is a useful program.

Happy to help, and glad the issue is fixed for you. : )

As we were discussing in another thread, one potential way it can happen
is if a program crashes (or is force quit) before it has completely
written a file it has open (in this case, it might have had a cache file
open). There are other potential ways a cache file might become corrupt,
of course (bugs in software, and so on). Luckily, cache files are
typically rebuild automatically when needed. So deleting them is a
fairly safe thing to do.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21201

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2014-02-22, DushanM <dushanm@nnips.net> wrote:
> > Jolly Roger <jollyroger@pobox.com> wrote:
> >> 
> >> After you monitor the logs, another thing you could try is deleting all
> >> cache files. There are many utilities that can do this for you. One of
> >> them is Cocktail <https://www.macupdate.com/app/mac/10909/cocktail>. Run
> >> Cocktail, click the Files tab at the top of the window, check each of
> >> the check boxes (System, User, Internet) under the current user column,
> >> and then click the Clear button. Then restart your computer and see if
> >> the issue persists. This will tell you whether the problem is a cache
> >> file. (Note that Cocktail can also be configured to delete even more
> >> cache files than it does by default. See the Options button for
> >> details.)
> >> 
> >> After that, another thing you could try is logging out of the problem
> >> account, using an administrator account to move the contents of the
> >> problem user's ~/Library/Preferences folder to a temporary location
> >> (leaving the ~/Library/Preferences folder empty), and then logging back
> >> into the problem account to see if the problem is resolved. This would
> >> tell you whether the problem file is in the preferences folder.
> >> 
> >> Do try looking at the logs first. They may give you a clue as to
> >> exactly where the problem lies without having to mess with cache and
> >> preferences files.
> >
> > Clearing the cache worked!
> >
> > First I did look at the log file in Console, and that showed absolutely
> > no new message when the pointer comes up against a link.  So following
> > your suggestion I downloaded Cocktail and deleted first all the Internet
> > cache files.  That made no difference.  Then I went back into Cocktail
> > and deleted the User cache files (I was trying to narrow it down a bit),
> > and restarted.  Now the pointer could move everywhere, as pointing hand
> > or just arrow.
> >
> > Thank you much for that suggestion.  I'm still wondering, tho, how that
> > particular glitch got there to begin with.  At least now I know how to
> > fix a recurrance.  Looks like Cocktail is a useful program.
> 
> Happy to help, and glad the issue is fixed for you. : )
> 
> As we were discussing in another thread, one potential way it can happen
> is if a program crashes (or is force quit) before it has completely
> written a file it has open (in this case, it might have had a cache file
> open). There are other potential ways a cache file might become corrupt,
> of course (bugs in software, and so on). Luckily, cache files are
> typically rebuild automatically when needed. So deleting them is a
> fairly safe thing to do.

Oops - I spoke too soon: this weekend the problem was back.  Now I'll
have to see whether it was just the restarting that made it go away
temporarily, or whether clearing out the cache was involved.  And if the
cache, maybe deleting the System cache will fix the problem for good.
Also, after the problem disappears I'll be on the lookout for what was
just done before it re-appeared.  It'll be Thursday before I can check
that, and will report back.

- Dushan

[toc] | [prev] | [next] | [standalone]

#21242

DushanM <dushanm@nnips.net> wrote:

> Jolly Roger <jollyroger@pobox.com> wrote:
> 
> > On 2014-02-22, DushanM <dushanm@nnips.net> wrote:
> > > Jolly Roger <jollyroger@pobox.com> wrote:
> > >> 
> > >> After you monitor the logs, another thing you could try is deleting all
> > >> cache files. There are many utilities that can do this for you. One of
> > >> them is Cocktail <https://www.macupdate.com/app/mac/10909/cocktail>. Run
> > >> Cocktail, click the Files tab at the top of the window, check each of
> > >> the check boxes (System, User, Internet) under the current user column,
> > >> and then click the Clear button. Then restart your computer and see if
> > >> the issue persists. This will tell you whether the problem is a cache
> > >> file. (Note that Cocktail can also be configured to delete even more
> > >> cache files than it does by default. See the Options button for
> > >> details.)
> > >> 
> > >> After that, another thing you could try is logging out of the problem
> > >> account, using an administrator account to move the contents of the
> > >> problem user's ~/Library/Preferences folder to a temporary location
> > >> (leaving the ~/Library/Preferences folder empty), and then logging back
> > >> into the problem account to see if the problem is resolved. This would
> > >> tell you whether the problem file is in the preferences folder.
> > >> 
> > >> Do try looking at the logs first. They may give you a clue as to
> > >> exactly where the problem lies without having to mess with cache and
> > >> preferences files.
> > >
> > > Clearing the cache worked!
> > >
> > > First I did look at the log file in Console, and that showed absolutely
> > > no new message when the pointer comes up against a link.  So following
> > > your suggestion I downloaded Cocktail and deleted first all the Internet
> > > cache files.  That made no difference.  Then I went back into Cocktail
> > > and deleted the User cache files (I was trying to narrow it down a bit),
> > > and restarted.  Now the pointer could move everywhere, as pointing hand
> > > or just arrow.
> > >
> > > Thank you much for that suggestion.  I'm still wondering, tho, how that
> > > particular glitch got there to begin with.  At least now I know how to
> > > fix a recurrance.  Looks like Cocktail is a useful program.
> > 
> > Happy to help, and glad the issue is fixed for you. : )
> > 
> > As we were discussing in another thread, one potential way it can happen
> > is if a program crashes (or is force quit) before it has completely
> > written a file it has open (in this case, it might have had a cache file
> > open). There are other potential ways a cache file might become corrupt,
> > of course (bugs in software, and so on). Luckily, cache files are
> > typically rebuild automatically when needed. So deleting them is a
> > fairly safe thing to do.
> 
> Oops - I spoke too soon: this weekend the problem was back.  Now I'll
> have to see whether it was just the restarting that made it go away
> temporarily, or whether clearing out the cache was involved.  And if the
> cache, maybe deleting the System cache will fix the problem for good.
> Also, after the problem disappears I'll be on the lookout for what was
> just done before it re-appeared.  It'll be Thursday before I can check
> that, and will report back.
> 
> - Dushan

I did a bit more experimentation and observed this:

# a restart is all that's needed to make the pointer-freeze problem
  disappear in my wife's account; no cache deleting is necessary

# the problem seems to stay gone so long as I stay on my wife's account,
  tho statistics are still sparse,

# but when I switch to my account and then back to my wife's, the prob-
  lem reappears

# meanwhile, I've done nothing in either account except invoke Firefox

I'll experiment more this w.e.

- Dushan

[toc] | [prev] | [next] | [standalone]

#21365

DushanM <dushanm@nnips.net> wrote:

> DushanM <dushanm@nnips.net> wrote:
> 
>  <snip>
> > 
> > Oops - I spoke too soon: this weekend the problem was back.  Now I'll
> > have to see whether it was just the restarting that made it go away
> > temporarily, or whether clearing out the cache was involved.  And if the
> > cache, maybe deleting the System cache will fix the problem for good.
> > Also, after the problem disappears I'll be on the lookout for what was
> > just done before it re-appeared.  It'll be Thursday before I can check
> > that, and will report back.
> > 
> > - Dushan
> 
> I did a bit more experimentation and observed this:
> 
> # a restart is all that's needed to make the pointer-freeze problem
>   disappear in my wife's account; no cache deleting is necessary
> 
> # the problem seems to stay gone so long as I stay on my wife's account,
>   tho statistics are still sparse,
> 
> # but when I switch to my account and then back to my wife's, the prob-
>   lem reappears
> 
> # meanwhile, I've done nothing in either account except invoke Firefox
> 
> I'll experiment more this w.e.
> 
> - Dushan

I've little to add to the above, except that I don't have to do anything
at all to re-introduce the pointer problem in my wife's account except
switch to my account, then immediately back: the problem's there.  So
apparently the switching itself was responsible, probably when account
data was being re-assembled.  So what is done in that process that is
not done during restart (the restart is directly to my wife's account)?

[toc] | [prev] | [next] | [standalone]

#21366

On 2014-03-06, DushanM <dushanm@nnips.net> wrote:
> DushanM <dushanm@nnips.net> wrote:
>
>> DushanM <dushanm@nnips.net> wrote:
>> 
>>  <snip>
>> > 
>> > Oops - I spoke too soon: this weekend the problem was back.  Now I'll
>> > have to see whether it was just the restarting that made it go away
>> > temporarily, or whether clearing out the cache was involved.  And if the
>> > cache, maybe deleting the System cache will fix the problem for good.
>> > Also, after the problem disappears I'll be on the lookout for what was
>> > just done before it re-appeared.  It'll be Thursday before I can check
>> > that, and will report back.
>> > 
>> > - Dushan
>> 
>> I did a bit more experimentation and observed this:
>> 
>> # a restart is all that's needed to make the pointer-freeze problem
>>   disappear in my wife's account; no cache deleting is necessary
>> 
>> # the problem seems to stay gone so long as I stay on my wife's account,
>>   tho statistics are still sparse,
>> 
>> # but when I switch to my account and then back to my wife's, the prob-
>>   lem reappears
>> 
>> # meanwhile, I've done nothing in either account except invoke Firefox
>> 
>> I'll experiment more this w.e.
>> 
>> - Dushan
>
> I've little to add to the above, except that I don't have to do anything
> at all to re-introduce the pointer problem in my wife's account except
> switch to my account, then immediately back: the problem's there.  So
> apparently the switching itself was responsible, probably when account
> data was being re-assembled.  So what is done in that process that is
> not done during restart (the restart is directly to my wife's account)?

Something must get cached. You previously said that deleting cache files
temporarily fixed the issue, right? 

I believe you can find out which cache files are being deleted by
examining the system log after deleting them. That may be a place to
start. You could try manually (selectively) deleting certain ones or
groups of them to see which one(s) are at fault.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21384

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2014-03-06, DushanM <dushanm@nnips.net> wrote:
> > DushanM <dushanm@nnips.net> wrote:
> >
> >> DushanM <dushanm@nnips.net> wrote:
> >> 
> >>  <snip>
> >> > 
> >> > Oops - I spoke too soon: this weekend the problem was back.  Now I'll
> >> > have to see whether it was just the restarting that made it go away
> >> > temporarily, or whether clearing out the cache was involved.  And if the
> >> > cache, maybe deleting the System cache will fix the problem for good.
> >> > Also, after the problem disappears I'll be on the lookout for what was
> >> > just done before it re-appeared.  It'll be Thursday before I can check
> >> > that, and will report back.
> >> > 
> >> > - Dushan
> >> 
> >> I did a bit more experimentation and observed this:
> >> 
> >> # a restart is all that's needed to make the pointer-freeze problem
> >>   disappear in my wife's account; no cache deleting is necessary
> >> 
> >> # the problem seems to stay gone so long as I stay on my wife's account,
> >>   tho statistics are still sparse,
> >> 
> >> # but when I switch to my account and then back to my wife's, the prob-
> >>   lem reappears
> >> 
> >> # meanwhile, I've done nothing in either account except invoke Firefox
> >> 
> >> I'll experiment more this w.e.
> >> 
> >> - Dushan
> >
> > I've little to add to the above, except that I don't have to do anything
> > at all to re-introduce the pointer problem in my wife's account except
> > switch to my account, then immediately back: the problem's there.  So
> > apparently the switching itself was responsible, probably when account
> > data was being re-assembled.  So what is done in that process that is
> > not done during restart (the restart is directly to my wife's account)?
> 
> Something must get cached. You previously said that deleting cache files
> temporarily fixed the issue, right? 
> 
> I believe you can find out which cache files are being deleted by
> examining the system log after deleting them. That may be a place to
> start. You could try manually (selectively) deleting certain ones or
> groups of them to see which one(s) are at fault.

Oh, maybe I see what you're driving at: when accounts get switched, data
in the 'from' account gets cached, then re-introduced when that account
is re-entered.  And this does not happen - or at least not identically -
during a restart.  Is that the general idea?

I can certainly try inventorying the cache files before and after a
restart and an account switch, and comparing.  But then it would seem as
if the switching operation itself somehow carries the infection, or at
least activates it, since it wasn't active before the switch after a
restart.  The mechanism for this is more and more puzzling to me.

I try the cache inspection approach and see what I learn.

Thanks for bearing with me on this problem.

- Dushan

[toc] | [prev] | [next] | [standalone]

#21385

On 2014-03-08, DushanM <dushanm@nnips.net> wrote:
> Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2014-03-06, DushanM <dushanm@nnips.net> wrote:
>> > DushanM <dushanm@nnips.net> wrote:
>> >
>> >> DushanM <dushanm@nnips.net> wrote:
>> >> 
>> >>  <snip>
>> >> > 
>> >> > Oops - I spoke too soon: this weekend the problem was back.  Now I'll
>> >> > have to see whether it was just the restarting that made it go away
>> >> > temporarily, or whether clearing out the cache was involved.  And if the
>> >> > cache, maybe deleting the System cache will fix the problem for good.
>> >> > Also, after the problem disappears I'll be on the lookout for what was
>> >> > just done before it re-appeared.  It'll be Thursday before I can check
>> >> > that, and will report back.
>> >> > 
>> >> > - Dushan
>> >> 
>> >> I did a bit more experimentation and observed this:
>> >> 
>> >> # a restart is all that's needed to make the pointer-freeze problem
>> >>   disappear in my wife's account; no cache deleting is necessary
>> >> 
>> >> # the problem seems to stay gone so long as I stay on my wife's account,
>> >>   tho statistics are still sparse,
>> >> 
>> >> # but when I switch to my account and then back to my wife's, the prob-
>> >>   lem reappears
>> >> 
>> >> # meanwhile, I've done nothing in either account except invoke Firefox
>> >> 
>> >> I'll experiment more this w.e.
>> >> 
>> >> - Dushan
>> >
>> > I've little to add to the above, except that I don't have to do anything
>> > at all to re-introduce the pointer problem in my wife's account except
>> > switch to my account, then immediately back: the problem's there.  So
>> > apparently the switching itself was responsible, probably when account
>> > data was being re-assembled.  So what is done in that process that is
>> > not done during restart (the restart is directly to my wife's account)?
>> 
>> Something must get cached. You previously said that deleting cache files
>> temporarily fixed the issue, right? 
>> 
>> I believe you can find out which cache files are being deleted by
>> examining the system log after deleting them. That may be a place to
>> start. You could try manually (selectively) deleting certain ones or
>> groups of them to see which one(s) are at fault.
>
> Oh, maybe I see what you're driving at: when accounts get switched, data
> in the 'from' account gets cached, then re-introduced when that account
> is re-entered.  And this does not happen - or at least not identically -
> during a restart.  Is that the general idea?

My theory is because deleting caches fixes the problem, that's what is
happening.

> I can certainly try inventorying the cache files before and after a
> restart and an account switch, and comparing.  But then it would seem as
> if the switching operation itself somehow carries the infection, or at
> least activates it, since it wasn't active before the switch after a
> restart.  The mechanism for this is more and more puzzling to me.
>
> I try the cache inspection approach and see what I learn.
>
> Thanks for bearing with me on this problem.

I think if you can figure out which specific cache file(s) are involved,
that will lead you to the root caused (and the solution).

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#21476

Jolly Roger <jollyroger@pobox.com> wrote:

> On 2014-03-08, DushanM <dushanm@nnips.net> wrote:
> > Jolly Roger <jollyroger@pobox.com> wrote:
> >
> >> On 2014-03-06, DushanM <dushanm@nnips.net> wrote:
> >> > DushanM <dushanm@nnips.net> wrote:
> >> >
> >> >> DushanM <dushanm@nnips.net> wrote:
> >> >> 
> >> >>  <snip>
> >> >> > 
> >> >> > Oops - I spoke too soon: this weekend the problem was back.  Now
> >> >> > I'll have to see whether it was just the restarting that made it
> >> >> > go away temporarily, or whether clearing out the cache was
> >> >> > involved.  And if the cache, maybe deleting the System cache will
> >> >> > fix the problem for good. Also, after the problem disappears I'll
> >> >> > be on the lookout for what was just done before it re-appeared.
> >> >> > It'll be Thursday before I can check that, and will report back.
> >> >> > 
> >> >> > - Dushan
> >> >> 
> >> >> I did a bit more experimentation and observed this:
> >> >> 
> >> >> # a restart is all that's needed to make the pointer-freeze problem
> >> >>   disappear in my wife's account; no cache deleting is necessary
> >> >> 
> >> >> # the problem seems to stay gone so long as I stay on my wife's
> >> >> account, tho statistics are still sparse,
> >> >> 
> >> >> # but when I switch to my account and then back to my wife's, the
> >> >> problem reappears
> >> >> 
> >> >> # meanwhile, I've done nothing in either account except invoke
> >> >> Firefox
> >> >> 
> >> >> I'll experiment more this w.e.
> >> >> 
> >> >> - Dushan
> >> >
> >> > I've little to add to the above, except that I don't have to do
> >> > anything at all to re-introduce the pointer problem in my wife's
> >> > account except switch to my account, then immediately back: the
> >> > problem's there.  So apparently the switching itself was responsible,
> >> > probably when account data was being re-assembled.  So what is done
> >> > in that process that is not done during restart (the restart is
> >> > directly to my wife's account)?
> >> 
> >> Something must get cached. You previously said that deleting cache
> >> files temporarily fixed the issue, right?
> >> 
> >> I believe you can find out which cache files are being deleted by
> >> examining the system log after deleting them. That may be a place to
> >> start. You could try manually (selectively) deleting certain ones or
> >> groups of them to see which one(s) are at fault.
> >
> > Oh, maybe I see what you're driving at: when accounts get switched, data
> > in the 'from' account gets cached, then re-introduced when that account
> > is re-entered.  And this does not happen - or at least not identically -
> > during a restart.  Is that the general idea?
> 
> My theory is because deleting caches fixes the problem, that's what is
> happening.
> 
> > I can certainly try inventorying the cache files before and after a
> > restart and an account switch, and comparing.  But then it would seem as
> > if the switching operation itself somehow carries the infection, or at
> > least activates it, since it wasn't active before the switch after a
> > restart.  The mechanism for this is more and more puzzling to me.
> >
> > I try the cache inspection approach and see what I learn.
> >
> > Thanks for bearing with me on this problem.
> 
> I think if you can figure out which specific cache file(s) are involved,
> that will lead you to the root caused (and the solution).

Yesterday I spent several hours trying our different things, and learned
a little, but not what caused the problem or how to fix it.

0 in each case below the initial condition was the same: restart into my
  wife's acct, with no sign of the problem;

1 I manually deleled every cache I could find on my wife's acct, both
  system and user, switched to my acct and back, and the problem came
  back;

2 ... then did the same thing using Cocktail, in case I'd missed some-
  thing, and got identical results;

3 did nothing (no cache clearing), switched to the Guest acct and back,
  and the problem was still gone;

4 did nothing (no cache clearing), logged out of wife's acct then logged
  back into it, and the problem was still gone.

These observations indicate that in fact clearing cache does not fix the
problem; only restarting does.

To summarize:
-- switching from wife's acct to my acct, and _only_ to my acct, brought
   on the problem
-- restarting is the only way I found to get rid of the problem - tempo-
   rarily until I switch to my acct
-- I did not see deleting cache have any visible effect on the above be-
   havior

So the question seems to be, how does a momentary switch to my acct con-
taminate my wife's on return?

Can you suggest more experiments?  I thought of one: create a new acct
and see what effect it has on switching to it and back.

- Dushan

 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.mac.apps

csiph-web