This is a bit too intense. When a second parameter is not given, Zotero will, by default, monitor element addition/removal of all descendant elements and trigger detectWeb. When monitoring <body> that could end up triggering _a lot_. E.g. on factiva, when you scroll your mouse over the filters on the left, you see the red circle appear next to each parameter. Each time the circle appears/disappears, an element is added/removed and Zotero will trigger detectWeb. It could get quite excessive (should be able to see a lot of messages about this in the debug log). Fortunately, you can usually narrow down the elements that need to be monitored.

In this case, you can trigger detectWeb when switching from search results to individual items (and vice versa) by monitoring the class attribute of the <body> tag. To do this, use
```
Z.monitorDOMChanges(doc.body, { attributes: true });
```
You can see more options for this [here](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver#MutationObserverInit) and you could even be more specific about which attributes to monitor via `attributeFilter` parameter (in this case it could be `attributeFilter: ['class']`, but it's only one attribute that changes anyway, so there's no point).

This, however, would not pick up on switching from one display mode to another (within a specific item). You could play around with that (probably monitoring addition/removal of direct children from <div id="articleFrame">), but I don't think you need to re-trigger on this anyway.