Looks like there is some infinite recursion happening; can you investigate this test failure?

Currently I don't understand why this recursion happens, but it origins from my changes to the boundingRect.

It doesn't happen, if I put this boundingRect adjustment into GraphicsWidget.boundingRect instead of ViewBox.boundingRect, which I also don't understand.
Maybe it has something to do with the caching of the boundingRect within GraphicsWidget?!
I need to investigate this further...

But since the issue with the boundingRect (2. in PR message) is independent of the issue with the axis baselines (1. in PR message) I would like to handle this separately and create another issue / PR.
Therefore I reverted the changes to the boundingRect.

So, at the present state, this PR solves the problems for at least the left and upper edge of the plot.

I find that the recursion error stops if you return a copy of the QRectF instead of modifying it.

def boundingRect(self):
    br = super().boundingRect()
    return br.adjusted(-0.5, 0, +0.5, +0.5)

I suppose if the parent class caches its boundingRect and returns a reference to that cached copy, then having the child modify it in-place would be catastrophic.

Could you explain the reason for the asymmetry in the bounds adjustment?

I did a look through the various items that provide an boundingRect implementation. Almost all of them (intentionally or otherwise) return a copy of QRectF.
The exceptions are:

• PlotCurveItem
• LinearRegionItem
• InfiniteLine
• GraphicsWidget

A related change to fix your PR would be to make GraphicsWidget return a copy:

def boundingRect(self):
    # snip
    return QtCore.QRectF(br)

It's unclear whether GraphicsWidget as a base class should protect itself by always returning a copy or whether it should rely on its child classes to be well-behaved enough to treat its returned QRectF as read-only.
The same comment might possibly apply to GraphicsWidget::shape().

I'm team modify GraphicsWidget, although @campagnola may have other opinions. We generally expect downstream users to subclass from GraphicsWidget in their own plot implementations, this seems safer than trying to ensure that other users know not to modify the rect that boundingRect returns instead of returning a new copy.

Thank you for your help.

I added the fix to ViewBox.boundingRect() again, but this time returning a copy.
Further I changed GraphicsWidget.boundingRect() to return a copy.
I think, boundingRect() should always return a copy, just to prevent strange behaviour as I experienced here. Therefore I changed it now in both classes, although it wouldn't be necessary.

Regarding the asymmetry in the bounds adjustment, I removed it.
I changed it to (0, 0, +0.5, +0.5) instead of (-0.5, 0, +0.5, +0.5).
With my example code above, the InfiniteLine at the left edge still disappears in some rare cases. I need to change the width of the window to reproduce this.
Initially I thought, the -0.5 makes this less often happen, but it was probably just a delusive hope.

Thanks @bbc131 for the PR and for incorporating suggested changes, thanks @pijyoi for your feedback. LGTM, merging.

Another idea regarding the axis baselines I had, was to let the InfiniteLine be drawn in front of the axis baseline, but this didn't work. The axis' z-value is 0.5 and I can set the InfiniteLine's z-value to anything larger than this but it's still not visible. I guess this has something to do with the parent-child relationships within the scene but I didn't analyzed this further.

This has to do with the following hierarchy:

PlotItem
+--> ViewBox (zValue = -100)
      +--> InfiniteLine
+--> AxisItem (zValue = 0.5)

zValues are only considered for ordering of siblings. Therefore, InfiniteLine, as a child of ViewBox, will always get drawn before AxisItem.