Filebrowser "Open File" button disappear when double-click thumbnail #51969

New Issue

Dalai Felinto · 2017-07-04T11:16:38+02:00

Dalai Felinto commented

2017-07-04 11:16:38 +02:00

Blender Version
Broken: 2.8x
Worked: 2.7x

Short description of error
To open images or .blend with thumbnail leads to issues.

Exact steps for others to reproduce the error

Open filebrowser (F1)
Click on thumbnail preview in a folder with a few Blender files
Double-click in one of the thumbnails to open the blend file.

The file is not opened and the "Open Blender File" button disappears.

**Blender Version** Broken: 2.8x Worked: 2.7x **Short description of error** To open images or .blend with thumbnail leads to issues. **Exact steps for others to reproduce the error** * Open filebrowser (F1) * Click on thumbnail preview in a folder with a few Blender files * Double-click in one of the thumbnails to open the blend file. The file is not opened and the "Open Blender File" button disappears.

Dalai Felinto commented

2017-07-04 11:16:38 +02:00

Changed status to: 'Open'

Dalai Felinto commented

2017-07-04 11:16:38 +02:00

Added subscriber: @dfelinto

blender-admin commented

2017-07-04 11:16:38 +02:00

#52061 was marked as duplicate of this issue

Bastien Montagne was assigned by Dalai Felinto

2017-07-04 11:17:54 +02:00

Steffen Dünner commented

2017-07-04 11:33:00 +02:00

Added subscriber: @SteffenD

Bastien Montagne commented

2017-07-05 09:39:45 +02:00

Eeeeh… Not sure what I can do here, this is an OpenGL bug I think.

I can reproduce the issue when running on my laptop GPU (NVidia 850m, 375.66 drivers, with bumblebee/optimus), but not when running on integrated Intel 'gpu' (and Mesa drivers I suppose)… :/

Eeeeh… Not sure what I can do here, this is an OpenGL bug I think. I can reproduce the issue when running on my laptop GPU (NVidia 850m, 375.66 drivers, with bumblebee/optimus), but not when running on integrated Intel 'gpu' (and Mesa drivers I suppose)… :/

Dalai Felinto commented

2017-07-16 11:42:20 +02:00

Added subscriber: @nezumi

Bastien Montagne commented

2017-07-19 17:56:13 +02:00

OK, sooooo… On second thought (and much investigation) I do not think it's actually related to OpenGL.

Thing is, on my laptop I nearly never can reproduce the issue (only happens like a few % of times). On studio workstation it happens like 99% of time.

Using tmp-debug-filebrowser, added bunch of prints everywhere, and… I don’t understand what happens currently. It seems that on buggy machine, event added by 'exec' filebrowser operator is handled nearly immediately, and in a wrong way, by the event handler loop, while on machine which is working OK that FILESELECT event gets handled later (as expected), on some next run of handler loop.

Also quite mysterious why it does not fail in master - personal hypothesis would be, new OGL code in 2.8 can (with good GPU) be much, much more efficient, so event loop can be ran more often, and somehow it ends up walking on its own tail. Will keep digging tomorrow.

OK, sooooo… On second thought (and much investigation) I do not think it's actually related to OpenGL. Thing is, on my laptop I nearly never can reproduce the issue (only happens like a few % of times). On studio workstation it happens like 99% of time. Using tmp-debug-filebrowser, added bunch of prints everywhere, and… I don’t understand what happens currently. It *seems* that on buggy machine, event added by 'exec' filebrowser operator is handled nearly immediately, and in a wrong way, by the event handler loop, while on machine which is working OK that `FILESELECT` event gets handled later (as expected), on some next run of handler loop. Also quite mysterious why it does not fail in master - personal hypothesis would be, new OGL code in 2.8 can (with good GPU) be much, much more efficient, so event loop can be ran more often, and somehow it ends up walking on its own tail. Will keep digging tomorrow.

blender-admin commented

2017-07-19 21:42:41 +02:00

This issue was referenced by 827dc700ba

This issue was referenced by 827dc700baf177a4fbf54e52cedc945eb4c60391

Julian Eisel commented

2017-07-19 21:50:31 +02:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2017-07-19 21:50:31 +02:00

Julian Eisel commented

2017-07-19 22:01:57 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2017-07-19 22:01:57 +02:00

Spent some time investigating this and noticed the difference to master is that the file-open handler is not stored in wmWindow.modalhandlers but in wmWindow.handlers, which have a much lower priority. So probably some other handler returned WM_HANDLER_BREAK, blocking the handling of wmWindow.handlers (just guessing on this, didn't investigate deeper).

So turns out this is caused by 82ba89b042. I reverted it and added an alternative fix that should work without any side-effects (827dc700ba).

Spent some time investigating this and noticed the difference to master is that the file-open handler is not stored in `wmWindow.modalhandlers` but in `wmWindow.handlers`, which have a much lower priority. So probably some other handler returned `WM_HANDLER_BREAK`, blocking the handling of `wmWindow.handlers` (just guessing on this, didn't investigate deeper). So turns out this is caused by 82ba89b042. I reverted it and added an alternative fix that should work without any side-effects (827dc700ba).

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Filebrowser "Open File" button disappear when double-click thumbnail #51969