internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: napari/napari

Issue:
clipping plane and plane rendering appear to not be aligned
## 🐛 Bug

When using the same plane parameters for a layer with a clipping plane and a layer with a slicing plane, they appear to not be aligned (see screenshot below).

<img width="1059" alt="Screenshot 2021-08-27 at 07 27 41" src="https://user-images.githubusercontent.com/1120672/131076586-1ad9b5ca-06fb-4ff9-8af5-8202514d1e26.png">


## To Reproduce

<details>
  <summary>Click to expand!</summary>
  
  ```python
import napari
import numpy as np


data = np.zeros((384, 513, 513))
data[100:300, 100:400, 100:400] = 1

plane_parameters = {
    'position': [ 87.35316989, 104.39580705, 296.60489348],
    'normal':  [0.56115536, -0.82554534, -0.05982944],
    'thickness': 5,
    'enabled': True
}

viewer = napari.view_image(
    data,
    experimental_clipping_planes=[plane_parameters],
    name='clipping plane'
)

plane_layer = viewer.add_image(
    data,
    experimental_slicing_plane=plane_parameters,
    rendering='translucent',
    colormap='magenta',
    name='slicing plane'
)

viewer.dims.ndisplay = 3
napari.run()


  ```
</details>

## Expected behavior

I would expect the planes to be coincident.

## Environment
napari: 0.4.11rc2
Platform: macOS-10.15.7-x86_64-i386-64bit
System: MacOS 10.15.7
Python: 3.8.11 (default, Aug 6 2021, 08:56:27) [Clang 10.0.0 ]
Qt: 5.15.2
PyQt5: 5.15.4
NumPy: 1.21.2
SciPy: 1.7.1
Dask: 2021.08.1
VisPy: 0.8.0

OpenGL:
- GL version: 2.1 INTEL-14.7.17
- MAX_TEXTURE_SIZE: 16384

Screens:
- screen 1: resolution 1440x900, scale 2.0

Plugins:
- console: 0.0.3
- scikit-image: 0.4.11rc2
- svg: 0.1.5




Discussion:
It's a bit easier to see with a movie:


https://user-images.githubusercontent.com/1120672/131077060-52686e5c-a10a-4ee0-9c46-729f4e1ae9f9.mov


Oh wow, thanks for picking this up @kevinyamauchi ! Will have to have a thorough check of what's going on here
It seems to be a shape-related issue. Things only break if the volume is non-cubic (we didn't do a great job at testing, it seems ^^').

Resolving patch:
diff --git a/napari/_vispy/vendored/volume.py b/napari/_vispy/vendored/volume.py
--- a/napari/_vispy/vendored/volume.py
+++ b/napari/_vispy/vendored/volume.py
@@ -990,7 +990,7 @@ def _build_clipping_planes_func(n_planes):
             '''
         clip_template = '''
             vec3 relative_vec{idx} = loc - ( u_clipping_plane_pos{idx} / vol_shape );
-            float is_shown{idx} = dot(relative_vec{idx}, u_clipping_plane_norm{idx});
+            float is_shown{idx} = dot(relative_vec{idx}, (u_clipping_plane_norm{idx} * vol_shape));
             is_shown = min(is_shown{idx}, is_shown);
             '''
         all_vars = []


Test patch:
Repository: napari/napari

Issue:
Linux bundle build failing
## 🐛 Bug
I know it probably doesn't get used much, but we should either fix the failing Linux bundle build, or skip it for now, since it will make all of our master branch tests look like they're failing.    best I can tell from the [logs](https://github.com/napari/napari/runs/3331141461?check_suite_focus=true),  this might be an issue?
```
-- Running output plugin: appimage -- 
[appimage/stdout] Found appimagetool: /tmp/appimage_extracted_1cdfc4fa2d98741b846c2cf3d6a277cc/plugins/linuxdeploy-plugin-appimage/usr/bin/appimagetool
[appimage/stdout] 
[appimage/stdout] WARNING: appstreamcli command is missing, please install it if you want to use AppStream metadata
[appimage/stderr] Running command: /tmp/appimage_extracted_1cdfc4fa2d98741b846c2cf3d6a277cc/plugins/linuxdeploy-plugin-appimage/usr/bin/appimagetool "/home/runner/work/napari/napari/linux/napari/napari.AppDir" "-g"
[appimage/stderr] 
[appimage/stderr] appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
[appimage/stderr] More than one architectures were found of the AppDir source directory "/home/runner/work/napari/napari/linux/napari/napari.AppDir"
[appimage/stderr] A valid architecture with the ARCH environmental variable should be provided
[appimage/stderr] e.g. ARCH=x86_64 appimagetool ...
ERROR: Failed to run plugin: appimage (exit code: 1) 
Error while building app napari.
```

cc @ziyangczi, @goanpeca 


Discussion:
Looking into this, hopefully I can address the issue along with ubuntu version upgrade
 Pinging @jaimergp
I'm looking into this! @ziyangczi Should we sync? Ubuntu 16 doesn't ship a recent enough libssh I think. I am going to try with 18.04 and see if that fixes it. Is there any reason we are stuck with 16.04?

Resolving patch:
diff --git a/bundle.py b/bundle.py
--- a/bundle.py
+++ b/bundle.py
@@ -203,6 +203,10 @@ def patch_python_lib_location():
         print("symlinking", orig, "to", dest)
 
 
+def patch_environment_variables():
+    os.environ["ARCH"] = os.uname().machine
+
+
 def make_zip():
     import glob
     import zipfile
@@ -232,6 +236,9 @@ def bundle():
     if MACOS:
         patch_dmgbuild()
 
+    if LINUX:
+        patch_environment_variables()
+
     # smoke test, and build resources
     subprocess.check_call([sys.executable, '-m', APP, '--info'])
 
@@ -250,7 +257,6 @@ def bundle():
         elif MACOS:
             patch_python_lib_location()
 
-        sys.exit(0)
         # build
         cmd = ['briefcase', 'build'] + (['--no-docker'] if LINUX else [])
         subprocess.check_call(cmd)


Test patch:
Repository: napari/napari

Issue:
Standardize platform architectures?
## 🧰 Task
<!-- A clear and concise description of the task -->

With the new naming scheme followed in the bundles (introduced by #3302), we suffix the zipname with `x86_64` on Unix and `amd64` on Windows. See [here](https://github.com/napari/napari/actions/runs/1201969002) for an example.

This is because we use `platform.machine()`, which does not try to canonicalize arch names across OSs, but instead [tries to return the most common vocabulary in each OS](https://bugs.python.org/issue7146). Do we want a consistent naming scheme here or not? I guess we only need to map AMD64 back to `x86_64` but happy to hear your thoughts.




Discussion:

Resolving patch:
diff --git a/bundle.py b/bundle.py
--- a/bundle.py
+++ b/bundle.py
@@ -207,7 +207,16 @@ def patch_python_lib_location():
 
 
 def patch_environment_variables():
-    os.environ["ARCH"] = ARCH
+    os.environ["ARCH"] = architecture()
+
+
+def architecture():
+    arch = platform.machine() or "generic"
+    # Try to canonicalize across OS
+    replacements = {
+        "amd64": "x86_64",
+    }
+    return replacements.get(arch.lower(), arch)
 
 
 def make_zip():
@@ -283,4 +292,7 @@ def bundle():
     if '--version' in sys.argv:
         print(VERSION)
         sys.exit()
+    if '--arch' in sys.argv:
+        print(architecture())
+        sys.exit()
     print('created', bundle())


Test patch:
Repository: napari/napari

Issue:
`normalize_dtype` excludes big endian types
## 🐛 Bug
```py
In [457]: from napari.utils._dtype import get_dtype_limits

In [458]: get_dtype_limits(np.dtype('<u2'))
Out[458]: (0, 65535)

In [459]: get_dtype_limits(np.dtype('>u2'))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-459-d109d903c3cf> in <module>
----> 1 get_dtype_limits(np.dtype('>u2'))

~/Dropbox (HMS)/Python/forks/napari/napari/utils/_dtype.py in get_dtype_limits(dtype_spec)
    103         info = np.finfo(dtype)
    104     else:
--> 105         raise TypeError(f'Unrecognized or non-numeric dtype: {dtype_spec}')
    106     return info.min, info.max

TypeError: Unrecognized or non-numeric dtype: >u2

In [460]: np.iinfo('>u2')
Out[460]: iinfo(min=0, max=65535, dtype=>u2)
```


Discussion:

Resolving patch:
diff --git a/napari/utils/_dtype.py b/napari/utils/_dtype.py
--- a/napari/utils/_dtype.py
+++ b/napari/utils/_dtype.py
@@ -79,6 +79,11 @@ def normalize_dtype(dtype_spec):
         return _normalize_str_by_bit_depth(dtype_str, 'complex')
     if 'bool' in dtype_str:
         return np.bool_
+    # If we don't find one of the named dtypes, return the dtype_spec
+    # unchanged. This allows NumPy big endian types to work. See
+    # https://github.com/napari/napari/issues/3421
+    else:
+        return dtype_spec
 
 
 def get_dtype_limits(dtype_spec) -> Tuple[float, float]:


Test patch:
diff --git a/napari/utils/_tests/test_dtype.py b/napari/utils/_tests/test_dtype.py
--- a/napari/utils/_tests/test_dtype.py
+++ b/napari/utils/_tests/test_dtype.py
@@ -74,7 +74,10 @@ def test_pure_python_types(dtype_str):
         float,
         'float32',
         'float64',
-    ],
+        '>f4',
+        '>f8',
+    ]
+    + [''.join(t) for t in itertools.product('<>', 'iu', '1248')],
 )
 def test_dtype_lims(dtype):
     lims = get_dtype_limits(dtype)
Repository: napari/napari

Issue:
Backspace during Polygon Draw -> IndexError
## 🐛 Bug

backspace during poly draw triggers IntdexError

## To Reproduce

Steps to reproduce the behavior:

1. open napari
2. create shape layer
3. start a polygo
4. press backspace
5. IndexError.

https://gist.github.com/Carreau/433c7871a6bd8a8bc2d0f390ae56de51

## Expected behavior

Don't trigger index Error

## Environment

Latest master


## Additional context

<!-- Add any other context about the problem here. -->



Discussion:

Resolving patch:
diff --git a/napari/layers/shapes/_shapes_key_bindings.py b/napari/layers/shapes/_shapes_key_bindings.py
--- a/napari/layers/shapes/_shapes_key_bindings.py
+++ b/napari/layers/shapes/_shapes_key_bindings.py
@@ -139,7 +139,9 @@ def select_all_shapes(layer):
 @register_shapes_action(trans._('Delete any selected shapes'))
 def delete_selected_shapes(layer):
     """."""
-    layer.remove_selected()
+
+    if not layer._is_creating:
+        layer.remove_selected()
 
 
 @register_shapes_action(trans._('Move to front'))


Test patch:
Repository: napari/napari

Issue:
If a list of length one is passed to add_vectors as length, strange things happen
## 🐛 Bug

Passing something like `[1]` as length to `viewer.add_vectors()` leads to random windows opening.

## To Reproduce

```
viewer.add_vectors(np.random.rand(1,2,3), length=[1])
```
we get a reasonable error:
```
TypeError: setValue(self, float): argument 1 has unexpected type 'list'
```
but at the same time, these 2 windows open:
![image](https://user-images.githubusercontent.com/23482191/97780816-36de3800-1b87-11eb-8e02-f5698f126075.png)

Other non-number values give a range of errors that are hard to interpret, making it hard to debug in case something other than a number ended up there. For example:
```
UFuncTypeError: ufunc 'multiply' did not contain a loop with signature matching types (dtype('<U32'), dtype('<U32')) -> dtype('<U32')
```
to an unexperienced user like me would not suggest that `length` was a string.

## Expected behavior

No windows should open. Type checking should give more informative error messages.

## Environment

```
napari: 0.4.0
Platform: Linux-5.9.1-arch1-1-x86_64-with-glibc2.2.5
Python: 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0]
Qt: 5.15.1
PyQt5: 5.15.1
NumPy: 1.19.2
SciPy: 1.5.3
Dask: 2.30.0
VisPy: 0.6.5

GL version: 4.6 (Compatibility Profile) Mesa 20.2.1
MAX_TEXTURE_SIZE: 16384

Plugins:
- napari_plugin_engine: 0.1.8
- svg: 0.1.4
```


Discussion:
Thanks for reporting this! Right now length for vectors must be a single scalar, but I could imaging a length D vector makes sense if the vectors are in D dimensions. We should also handle the failure more gracefully!

Resolving patch:
diff --git a/napari/layers/vectors/vectors.py b/napari/layers/vectors/vectors.py
--- a/napari/layers/vectors/vectors.py
+++ b/napari/layers/vectors/vectors.py
@@ -203,8 +203,7 @@ def __init__(
         # Save the vector style params
         self._edge_width = edge_width
 
-        # length attribute
-        self._length = length
+        self._length = float(length)
 
         self._data = data
 
@@ -409,7 +408,7 @@ def length(self) -> Union[int, float]:
 
     @length.setter
     def length(self, length: Union[int, float]):
-        self._length = length
+        self._length = float(length)
 
         vertices, triangles = generate_vector_meshes(
             self.data[:, :, list(self._dims_displayed)],


Test patch:
Repository: napari/napari

Issue:
Docked widgets are resizeable outside of their enclosure
## 🐛 Bug

While checking out how to address #3620, I found out this:

https://user-images.githubusercontent.com/23482191/141996124-b45e4cbf-052d-479d-8943-ea3c0bfc984f.mp4

## To Reproduce

Click and drag just a tiny bit to the right of the resizing handle of the right side area.

## Environment

```yaml
napari: 0.4.12rc1.dev12+g99e61c4e
Platform: Linux-5.14.15-arch1-1-x86_64-with-glibc2.33
System: Arch Linux
Python: 3.9.7 (default, Oct 10 2021, 15:13:22) [GCC 11.1.0]
Qt: 5.15.2
PyQt5: 5.15.6
NumPy: 1.21.2
SciPy: 1.7.1
Dask: 2021.10.0
VisPy: 0.9.1

OpenGL:
- GL version: 4.6.0 NVIDIA 495.44
- MAX_TEXTURE_SIZE: 16384

Screens:
- screen 1: resolution 1920x1080, scale 1.0
- screen 2: resolution 1920x1200, scale 1.0

Plugins:
- animation: 0.0.2
- console: 0.0.3
- mrcfile-reader: 0.1.2
- napari-em-reader: 0.1.0
- napari-molecule-reader: 0.1.dev2+g06b598e.d20210914
- napari-properties-plotter: 0.2.0
- ndtiffs: 0.1.1
- ome-types: 0.2.9
- scikit-image: 0.4.9
- svg: 0.1.5
```



Discussion:
yeah 😆 ... that's an unfortunate "easter egg" that I've come across myself.  would be nice to fix
Is that related to magicgui @tlambert03 or the interaction within napari itself?
the [AnimationWizard](https://github.com/napari/napari-animation/blob/54aa0e5df0c64105d78a43d872eddc59c42475a5/napari_animation/_qt/animation_widget.py#L20) in the above example doesn't use magicgui, so this is a generic QWidget problem.  Maybe something in our QDockWidget wrapper though?
Oh, ok, that narrows it down. Thanks!

Resolving patch:
diff --git a/napari/_qt/menus/plugins_menu.py b/napari/_qt/menus/plugins_menu.py
--- a/napari/_qt/menus/plugins_menu.py
+++ b/napari/_qt/menus/plugins_menu.py
@@ -106,9 +106,13 @@ def _add_toggle_widget(*, key=key, hook_type=hook_type):
                     return
 
                 if hook_type == 'dock':
-                    self._win.add_plugin_dock_widget(*key)
+                    dock_widget, _w = self._win.add_plugin_dock_widget(*key)
                 else:
-                    self._win._add_plugin_function_widget(*key)
+                    dock_widget = self._win._add_plugin_function_widget(*key)
+
+                # Fixes https://github.com/napari/napari/issues/3624
+                dock_widget.setFloating(True)
+                dock_widget.setFloating(False)
 
             action.setCheckable(True)
             # check that this wasn't added to the menu already
diff --git a/napari/_qt/qt_main_window.py b/napari/_qt/qt_main_window.py
--- a/napari/_qt/qt_main_window.py
+++ b/napari/_qt/qt_main_window.py
@@ -717,7 +717,7 @@ def _add_plugin_function_widget(self, plugin_name: str, widget_name: str):
         func = plugin_manager._function_widgets[plugin_name][widget_name]
 
         # Add function widget
-        self.add_function_widget(
+        return self.add_function_widget(
             func, name=full_name, area=None, allowed_areas=None
         )
 


Test patch:
Repository: napari/napari

Issue:
Changing the mode of linked layers leads to RecursionError or crash
## 🐛 Bug

When the mode of a layer that is linked to another layer is changed napari crashes for me without error most of the time, even though I sometimes have seen a RecursionError. It looks to me like the interactive attribute of the layer oscillates between True and False, thereby bypassing the equality check that prevents recursions.

## To Reproduce

Steps to reproduce the behavior:

1. Add two point layers
2. Link the two layers
3. Switch on the of the layers into "Add" mode

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->






Discussion:

Resolving patch:
diff --git a/napari/layers/base/base.py b/napari/layers/base/base.py
--- a/napari/layers/base/base.py
+++ b/napari/layers/base/base.py
@@ -829,8 +829,8 @@ def help(self):
     def help(self, help):
         if help == self.help:
             return
-        self.events.help(help=help)
         self._help = help
+        self.events.help(help=help)
 
     @property
     def interactive(self):
@@ -839,10 +839,10 @@ def interactive(self):
 
     @interactive.setter
     def interactive(self, interactive):
-        if interactive == self.interactive:
+        if interactive == self._interactive:
             return
-        self.events.interactive(interactive=interactive)
         self._interactive = interactive
+        self.events.interactive(interactive=interactive)
 
     @property
     def cursor(self):
@@ -853,8 +853,8 @@ def cursor(self):
     def cursor(self, cursor):
         if cursor == self.cursor:
             return
-        self.events.cursor(cursor=cursor)
         self._cursor = cursor
+        self.events.cursor(cursor=cursor)
 
     @property
     def cursor_size(self):
@@ -865,8 +865,8 @@ def cursor_size(self):
     def cursor_size(self, cursor_size):
         if cursor_size == self.cursor_size:
             return
-        self.events.cursor_size(cursor_size=cursor_size)
         self._cursor_size = cursor_size
+        self.events.cursor_size(cursor_size=cursor_size)
 
     @property
     def experimental_clipping_planes(self):


Test patch:
diff --git a/napari/layers/utils/_tests/test_link_layers.py b/napari/layers/utils/_tests/test_link_layers.py
--- a/napari/layers/utils/_tests/test_link_layers.py
+++ b/napari/layers/utils/_tests/test_link_layers.py
@@ -154,3 +154,10 @@ def test_unlink_single_layer():
 
     unlink_layers([l1])  # completely unlink L1 from everything
     assert not l1.events.blending.callbacks
+
+
+def test_mode_recursion():
+    l1 = layers.Points(None, name='l1')
+    l2 = layers.Points(None, name='l2')
+    link_layers([l1, l2])
+    l1.mode = 'add'
Repository: napari/napari

Issue:
viewer.add_points fails on proxy viewer
## 🐛 Bug

Trying to add points to a public only proxy viewer fails:

```python
import napari
from napari.utils._proxies import PublicOnlyProxy

viewer = PublicOnlyProxy(napari.Viewer())
viewer.add_points()

napari.run()
```

Gives:

```pytb
Traceback (most recent call last):
  File "/home/jni/projects/play/public-only.py", line 5, in <module>
    viewer.add_points()
  File "/home/jni/projects/napari/napari/utils/_proxies.py", line 72, in __getattr__
    return self.create(super().__getattr__(name))
  File "/home/jni/projects/napari/napari/utils/_proxies.py", line 86, in create
    if not getattr(obj, '__module__', '').startswith('napari'):
AttributeError: 'NoneType' object has no attribute 'startswith'
```

fwiw since I encountered this while trying to prepare my plugins for the plugins meeting next week, imho we should leave this experiment until after the 16th, as most people are likely to be disrupted by it. (And other npe2-related enhancements since 0.4.12 are required to work with npe2, so sticking to 0.4.12 for the meeting is not an option.)


Discussion:
As mentioned in one on one chat, Im just fine with turning off the proxy for the next release if you want to, but this particular bug is a trivial fix

Resolving patch:
diff --git a/napari/utils/_proxies.py b/napari/utils/_proxies.py
--- a/napari/utils/_proxies.py
+++ b/napari/utils/_proxies.py
@@ -83,7 +83,8 @@ def __dir__(self):
     @classmethod
     def create(cls, obj: Any) -> Union['PublicOnlyProxy', Any]:
         # restrict the scope of this proxy to napari objects
-        if not getattr(obj, '__module__', '').startswith('napari'):
+        mod = getattr(type(obj), '__module__', None) or ''
+        if not mod.startswith('napari'):
             return obj
         if isinstance(obj, PublicOnlyProxy):
             return obj  # don't double-wrap


Test patch:
diff --git a/napari/utils/_tests/test_proxies.py b/napari/utils/_tests/test_proxies.py
--- a/napari/utils/_tests/test_proxies.py
+++ b/napari/utils/_tests/test_proxies.py
@@ -108,3 +108,8 @@ def test_receive_return_proxy_object():
 
     add_layer(layer)
     assert len(viewer.layers) == 2
+
+
+def test_viewer_method():
+    viewer = PublicOnlyProxy(ViewerModel())
+    assert viewer.add_points() is not None
Repository: napari/napari

Issue:
Occasional segmentation fault when running `update_preference_docs.py`
## 🐛 Bug

The `generate_images()` function on `docs/_scripts/update_preference_docs.py` occasionally results in a Segmentation Fault. This prevents the docs build.

## To Reproduce

Steps to reproduce the behavior:

1. Run `make docs` from the root napari folder.

Output (for approximately 9 out of 10 runs)

```
$ make docs
rm -rf docs/_build/
find docs/api ! -name 'index.rst' -type f -exec rm -f {} +
pip install -qr docs/requirements.txt
python docs/_scripts/update_preference_docs.py
make: *** [Makefile:7: docs] Segmentation fault (core dumped)
```

After this works once, generating all the images, if I comment the `generate_images()` function call the docs are built successfully with no other issues.

## Expected behavior

The docs are correctly built.

## Environment

napari: 0.4.13.dev129+g225d1548.d20211213
Platform: Linux-5.14.18-1-MANJARO-x86_64-with-glibc2.33
System: Manjaro Linux
Python: 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:23:11) [GCC 9.4.0]
Qt: 5.15.2
PyQt5: 5.15.6
NumPy: 1.21.4
SciPy: 1.7.3
Dask: 2021.11.2
VisPy: 0.9.4

OpenGL:
- GL version: 4.6 (Compatibility Profile) Mesa 21.2.5
- MAX_TEXTURE_SIZE: 16384

Screens:
- screen 1: resolution 1920x1080, scale 1.0
- screen 2: resolution 1920x1080, scale 1.0

Plugins:
- console: 0.0.4
- scikit-image: 0.4.13.dev129+g225d1548.d20211213
- svg: 0.1.5



Discussion:
I've run into this too on linux.  It almost always works for me if I run with xvfb locally though.  (Which happens on CI, and it never seems to fail there)
Not enough for me unfortunately :( 

```
$ xvfb-run python docs/_scripts/update_preference_docs.py
/usr/bin/xvfb-run: line 181: 35338 Segmentation fault      (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@"
```
well shoot :/

On Mon, Dec 13, 2021 at 11:38 AM Melissa Weber Mendonça <
***@***.***> wrote:

> Not enough for me unfortunately :(
>
> $ xvfb-run python docs/_scripts/update_preference_docs.py
> /usr/bin/xvfb-run: line 181: 35338 Segmentation fault      (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@"
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/napari/napari/issues/3813#issuecomment-992660786>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMI52MK5UOKIPBWQBELD43UQYOP7ANCNFSM5J6F4GVA>
> .
>


Resolving patch:
diff --git a/napari/_qt/qt_event_loop.py b/napari/_qt/qt_event_loop.py
--- a/napari/_qt/qt_event_loop.py
+++ b/napari/_qt/qt_event_loop.py
@@ -156,7 +156,7 @@ def get_app(
 
         # Intercept tooltip events in order to convert all text to rich text
         # to allow for text wrapping of tooltips
-        app.installEventFilter(QtToolTipEventFilter(app))
+        app.installEventFilter(QtToolTipEventFilter())
 
     if not _ipython_has_eventloop():
         notification_manager.notification_ready.connect(


Test patch: