I tried to add w.w.Event(pointer.Event{Type: pointer.Cancel}) to visibilitychange. The visibilitychange is triggered, I receive the StageEvents, but the pointer.Cancel seems to be ignored, in somehow. It's received in the pointer.Push, but doesn't remove the last click.

I don't know, weird. 😣

That bug is annoying if you are open another window (say window.open("https://google.com") when you click. Then, the mouse gets trapped because it triggers the button every time you return to Gio ( since the mouse is never released).

The workaround is to track the pointer.Released instead of pointer.Press.

I notice some bugs while testing on WASM and Windows (on Windows it's veeeeeery rare). On Android it might be possible to reproduce, but I didn't try, yet.

The issue is that Gio doens't send a pointer.Release if the mouse is never released. The mouse can be "never released" because switch the Window.

Easy way to reproduce the problem:

1. Open two tabs on Chrome.
2. In one tab (the first one) open the Gio app which contain some button (the Kitchen demo).
3. Press some button and keep pressed.
4. While your mouse still pressed, hit "CTRL + 2". It will switch to another tab (the second one).
5. Leave your mouse in that second tab.
6. Return to the Gio app.
7. Click anywhere in the Gio app (outside of the button).

Result: Even clicking outside of the button, the button will be triggered.

On Windows it's more difficult to reproduce, it happens once and I think it was related to that problem.

Maybe, once the "focus is lost" (system.StageEvent), the pointer must be reseted in somehow?! But the pointer.Push() doesn't have access to the current Stage of the app. 😶

Reverting that patch also makes the frame generates everytime, without op.Invalidate. :S

Reverting that patch fixes the issue. 🥳

The change is cc63a3aeb7320d8859fee009a970fbed7d1d3187.

Seems that have one bug on current Editor (and maybe other widgets). If the user is using Touch (pointer.Touch), and tries to scroll the text in the Editor, it will make impossible to click in the Editor again.

As a result, the user can't move the carret and can't focus on the Editor (if the focus is lost).

The step-by-step to reproduce the problem is:

1. Run the Kitchen Example on mobile device (or emulating; i.e https://gioui.org/files/wasm/kitchen/index.html).
2. Touch on the "Hint Editor" (single line editor).
3. Type some "long" word in the Editor.
4. Touch on the end of the text and, while pressing, move the fingers close to the start of the text.
5. Touch again in any part of the text: It will not work anymore, the Editor is dead. :|

I'm trying to fix that, but I'm out of luck. :|

On desktop that problem doesn't happen.

Far I know, you need OpenGL ES 3 (with sRGB and some floating-point support). Maybe it's related to https://todo.sr.ht/~eliasnaur/gio/172.

Can you sketch a use-case where you need the ordering you mention? I think we may be able to change op.Defer to run nested defers immediately after their containing defers.

In my use case, my design is the following:

• Header
• Body

The Body almost always use some layout.List to be able to scroll. I want to "Header" be always visible, so I use the op.Defer for Header and I render it after everything (using op.Offset and op.Stack) to enforce the order. So, in order of rendering it is: 1. Body; 2. Header.

If the "Body" contains some "Modal", it works. The "Modal"/"Pop-Up" will overlay any "Body" content, but doesn't overlay the "Header". That is what I expect and what I get. Fine.

However. One of my "Editor" have another op.Defer. So, if I put one "Editor" inside the "Modal" of the "Body" (in the end: Body -> Modal -> Editor), it breaks everything. The Editor can overlay the Header, since it's one op.Defer inside another (the modal).

The only way to fix that, is change the Header to 2x (or 3x) op.Defer. I'll try to make some in-code example of it.

I'm playing the op.Defer for while, I already notice some problems while using it. Consider the following code (https://play.golang.org/p/Lq2Kk6ZL7-J):

	// First Macro - Black
	op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
		clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops)
		paint.Fill(gtx.Ops, color.NRGBA{0, 0, 0, 255})
	}))

	// Second Macro - Red
	op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
		clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops)
		paint.Fill(gtx.Ops, color.NRGBA{255, 0, 0, 255})

		// Inner Macro - Blue
		op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
			clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops)
			paint.Fill(gtx.Ops, color.NRGBA{0, 0, 255, 255})
		}))
	}))

	// Third Macro - Green
	op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
		clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops)
		paint.Fill(gtx.Ops, color.NRGBA{0, 255, 0, 255})
	}))

This code have multiples op.Defer, all of them changes the color of the "screen". I think that the result would be "Green", since it's the last op.Defer in the code. However, the result is "Blue", which is the op.Defer inside another op.Defer.

That behavior is really dificult to handle. The only way to fix that is doing:

	op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
		op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
			op.Defer(gtx.Ops, Macro(gtx, func(gtx layout.Context) {
				clip.Rect{Max: gtx.Constraints.Max}.Add(gtx.Ops)
				paint.Fill(gtx.Ops, color.NRGBA{0, 255, 0, 255})
			}))
		}))
	}))

That code will enforce that the "Green" have a "deeper-op.Defer" than the "Blue". In the end: for every nested op.Defer I need to create a new op.Defer to make the last-one longer than any other.