Thanks for reporting this.
Could you please provide a clear list of steps, to allow others to reproduce the problems that you're facing? Thanks in advance!

(In reply to André Klapper from comment #1)
> Thanks for reporting this.
> Could you please provide a clear list of steps, to allow others to reproduce
> the problems that you're facing? Thanks in advance!

Hold super+alt+8 to enable the magnifier, then press alt+super+= at the same time. Then access the overview by pressing super and clicking on the icon with 9 dots on the dock found on the far left. From there you can see that icons off to the side are cut off. To view the bug with menus simply click on any element that uses a menu and move the cursor over it. You will notice that the cursor jerks thus moving the magnification view.

So is this being worked on or has it been abandoned like every other person's report involving similar issues?

I've filed tons of bugs for KDE and developers started working on them immediately. It is unfortunate that a project I looked up to a couple years ago has become so isolated.

You guys make it hard to test development releases of Gnome, challenging for important bugs to be fixed, and a pain in the ass to modify Gnome in any way due to how reliant each component of Gnome is upon the other.

I'm sorry if I appear to be an ass who whines about everything, but that's the way I see it.

Advice for the future: if it works don't fix it (Gnome 2) because obviously the Gnome team is incompotent of aiding the disabled user base. 

I'm not sure what to tell my clients. They are torn about the broken implementation of your magnifier and the rough edges of KDE. I thought by now Gnome would make a viable argument as to why people should make the switch to Linux. Unfortunately I was wrong. 

When you make a release of Gnome make sure it is stable in nearly every aspect. Until then I recommend you regress the current 'stable' version of Gnome to whatever was considered to be the latest working release. Until then, keep 3.17 in development and don't release 3.18 with bugs. It saves headaches.

(In reply to RJ Murdok from comment #3)
> So is this being worked on

There is no activity in this ticket, so probably not. 
Manpower is limited and based on volunteers in free software projects.

> You guys make it hard to test development releases of Gnome

That's something to potentially discuss on https://mail.gnome.org/mailman/listinfo/desktop-devel-list - curious why you consider it "hard".

> Advice for the future: if it works don't fix it (Gnome 2) because obviously
> the Gnome team is incompotent of aiding the disabled user base. 

Please see https://wiki.gnome.org/Foundation/CodeOfConduct before adding further comments. Nobody stops you from using a distribution based on GNOME 2. The accessibility stack has improved a lot since GNOME 2 (which does not mean that it has suddenly become bug-free). Please be welcome to discuss specific concerns on https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list and feel free to get involved to get important issues fixed (or get a service level agreement with your distributor to fix important issues for you).

Created attachment 308092 [details] [review]
magnifier: Avoid caret/focus viewport changes while the pointer moves

If there's a caret or focus move we should delay it until the pointer
is stationary for little while so as to avoid jittery and spurious
viewport movements.

---

(In reply to RJ Murdok from comment #2)
> Hold super+alt+8 to enable the magnifier, then press alt+super+= at
> the same time. Then access the overview by pressing super and
> clicking on the icon with 9 dots on the dock found on the far
> left. From there you can see that icons off to the side are cut off.

I think this is a symptom of the more general bug 659523.

> To view the bug with menus simply click on any element that uses a
> menu and move the cursor over it. You will notice that the cursor
> jerks thus moving the magnification view.

The attached patch should take care of this.

(In reply to RJ Murdok from comment #3)
> So is this being worked on or has it been abandoned like every other
> person's report involving similar issues?

I'm sorry, which reports? Can you provide specific instances?

> Advice for the future: if it works don't fix it (Gnome 2) because
> obviously the Gnome team is incompotent of aiding the disabled user
> base.

I understand that you might be frustrated but insulting people isn't
going to help you get bugs fixed. Also, please try to remain
objective, this is technical bug tracker.

Thank you a lot! I'll try applying the patch. I'm sorry for my frustration, but it's disspointing to see a bug that's been around for a while persist. Will this patch be merged with 3.17? I appreciate the work that goes into Gnome Shell, and that bug was really annoying.

@André Klapper Sorry for getting on your nerves. I'd just hate to see other features progress when a base function isn't properly working.

RJ: You didn't get "on my nerves", really, and I understand your frustration. I was more trying to elaborate on more effective ways to get things going. :)

@Rui Matos, can I expect this fix in Gnome 3.17.5 or will need to go through revision?

(In reply to RJ Murdok from comment #8)
> @Rui Matos, can I expect this fix in Gnome 3.17.5 or will need to go through
> revision?

So you can confirm that the patch fixes your issue?

(In reply to Florian Müllner from comment #9)
> (In reply to RJ Murdok from comment #8)
> > @Rui Matos, can I expect this fix in Gnome 3.17.5 or will need to go through
> > revision?
> 
> So you can confirm that the patch fixes your issue?

The patch works.

Review of attachment 308092 [details] [review]:

::: js/ui/magnifier.js
@@ +1091,3 @@
     scrollContentsTo: function(x, y) {
+        if (this._pointerIdleMonitor.get_idletime() < POINTER_REST_TIME) {
+            this._clearScrollContentsTimer();

This is called for either branch, so could just move this before the if block

@@ +1092,3 @@
+        if (this._pointerIdleMonitor.get_idletime() < POINTER_REST_TIME) {
+            this._clearScrollContentsTimer();
+            this._scrollContentsTimerId = Mainloop.timeout_add(POINTER_REST_TIME, Lang.bind(this, function() {

Is delaying always the right thing to do, or do we need to differentiate between caret/focus tracking and calls to the shiftContentsTo() DBus method? I guess not, but then I have no idea what users of the DBus interface are out there and what they expect ...

Created attachment 308220 [details] [review]
magnifier: Avoid caret/focus viewport changes while the pointer moves

--
(In reply to Florian Müllner from comment #11)
> Is delaying always the right thing to do, or do we need to
> differentiate between caret/focus tracking and calls to the
> shiftContentsTo() DBus method?  I guess not, but then I have no idea
> what users of the DBus interface are out there and what they expect

Good point, I missed that case. I think it's better to keep the
previous behavior for those callers, here's the revised patch.

Review of attachment 308220 [details] [review]:

LGTM

For the other issue please follow bug 659523.

Attachment 308220 [details] pushed as f5865e8 - magnifier: Avoid caret/focus viewport changes while the pointer moves