Yes, I can confirm that this appears to be working in 2.83 LTS. Not sure when it got fixed (or by what commit), but this task can be closed.

I like 'contiguous extrude' seems succinct and descriptive.

Please clarify what you mean by "committing the operation" and "undo without committing the operation".

committing the operation- when the operator is no longer running modal and has returned. in other words- while the operator panel with all of the operator properties is still visible.

This appears to be fixed in 2.81

Here's a video of it happening in face mode with the latest from git.

Scratch that- not happening in edge mode, but I was able to repro it in face mode. Since I went through the trouble of building Blender I went ahead and made a debug build to get a callstack, this is the output:

Good news, does not appear to be happening on the build I just made- so it may have been fixed by something else. I'll hammer on it for a bit longer and see if I can get it to break

Well, I'll post an update whenever either the 2.81 download finishes (it's been going for about 2 hours now, previous attempts have timed out) or the build I just started finishes.

I'm not sure if it's the same bug, but after a week of trying to solve a similar crash I came up with a repeatable crash. Note that my bug is not for the modifier, but the bevel operator: https://developer.blender.org/T69966

Yep, sorry for the delay- been busy. Here's a blend file, not much to it though, repro is as described in the original report and verified with a factory default 2.80

In T68888#764808, @Jean Da Costa (jeacom256) wrote:

From this thread on Blenderartists, my impression is that performance is a bigger concern, people are not happy about how slow edit mode is. If adding more checks for edges or a more complex mesh datastructure could be done without slowing even more the viewport it would be fine.

https://blenderartists.org/t/retopology-design-task/1172311/105

Thinking about it a bit more, I think we could solve some of issues you mentioned with a tagging solution if we left the support edges visible but displayed them in a slightly different way to indicate their nature. (See the mockup I've attached). In this example, you can see that the 'support edges' are tagged and displayed differently than normal edges. This would allow them to remain selectable like normal edges, and would inform the user about the underlying geometry that could have an impact on tools like bevel and inset. I imagine users could even select and manipulate them (re-connect them to different verts if the automatically generated solution is not optimal or interferes with a tool). I think this could also help new users understand the difference between an edge they can dissolve and an edge they cannot. It would be intuitive visual feedback to say "dotted edges are different than normal edges for these reasons, and cannot be dissolved". Currently there's a UX issue where a user could create an ngon like the one in my example and attempt to dissolve one of the supporting edges and have it fail without understanding why.

Howard, just for clarification, are the pros and cons you listed in relation to *actual* holes in faces (ie, multiple loops per face) or does that also apply to the tagging solution?

In T68888#759424, @Campbell Barton (campbellbarton) wrote:

We could have basic support for holes, eg: keep the mesh structure virtually the same as it is now, only adding flags to denote holes (add a flag for a complex polygon, and a flag for polygons after it to be used as holes).

This is something I've suggested in the past and agree that it's a good compromise solution. I have some mockups I would need to dig up but the idea was that if you flag ngon support edges and simply hide them, tool/addon authors can account for them and make their own decisions on what happens. For example, loop selection on the hole becomes trivial, where it takes two attempts currently due to the support edge breaking the loop (and no discernable difference between the user-made edge and the one added internally to support the ngons).

Figured it out- the missing keymap items were added to a version of they 3D View Generic keymap that has space_type='EMPTY' rather than 'VIEW_3D'

Ok, so I have some more information. This bug is being caused by bgl.glEnable( bgl.GL_POLYGON_SMOOTH )! I noticed that the issue was only happening when a particular studio script was triggered (which I'm not able to share here unfortunately), but if I comment that one line out the artifacts go away.

Confirmed, this is due to color calibration software- feel free to archive this bug!

After more investigation, I believe this is being caused by my studio's monitor color calibration- I've tested it on two other machines and have not been able to repro it. When I'm at my workstation again tomorrow I will try disabling the Spyder auto-calibration and verify that this is the case.

It happens on the default cube, there's nothing particularly special about the blend file but I'll attach it anyway. I imagine this is more to do with hardware?

Aha! now that is a detail that I was not aware of. I had incorrectly assumed that ui_scale was simply the value that appears in preferences->interface, I never actually queried the value. It does correctly report a ui_scale that takes dpi into consideration, and now that I have a multiplier I can create consistent results on any display. Thanks for the guidance!

In T66673#718427, @Brecht Van Lommel (brecht) wrote:

system.dpi should not be used, it's deprecated.

Instead scale any UI elements including text by this:
https://docs.blender.org/api/master/bpy.types.PreferencesSystem.html?highlight=system%20dpi#bpy.types.PreferencesSystem.ui_scale

It's not a feature request, so far as I know, unless I'm missing something. The issue is that there is no way to ensure the end result is 100% identical on different displays that have different dpi. it doesn't matter what I set the dpi to in blf.size, it will look incorrect regardless. For example, if I set the dpi in blf.size to bpy.context.preferences.system.dpi, I get the following result in my 4k monitor (with a dpi of 108, according to system.dpi):

sorry, got distracted! It's happening in Linux as well. Two videos from Ubuntu 18.10 attached. First video shows same repro in multiple UV editors in the UV workspace, second video shows that it's not happening in any other workspace! so bizarre, hopefully since it's so weird nobody else will run into it ?

This is actually still happening with sticky selection disabled! See attached video.

Yeah it should be happening with any object in that scene in that particular workspace. It could be a windows-specific thing, I'll try it on Linux when i get home from work and see if it repros there.

Yes, this is still happening with the latest build- but it's only happening in one particular layout, which is very odd. If I create a new UV editor elsewhere it doesn't happen, so this appears to be some sort of edge case. blend file attached if you'd like to see it in action.

This is happening with the latest version from the buildbot with factory settings loaded. Here is a video with simplified repro:

so then there is no way in Blender to do the common task of selecting alternating uv edge loops in a UV island without also selecting UV edges from a completely separate island. that's pretty awful, but you are right, it's not a bug- just awful by design. hopefully that will be improved someday.

Additionally, this behavior is not exhibited while sync selection is enabled:

Note that this also happens with incorrectly 'selected' edges in edge mode. This is virtually impossible to show in a video due to compression, so here's a screenshot.

For anyone else who might need this functionality, a workaround that I use is the following:

Ah, okay- the fix probably hasn't made its way over to the nightly builds yet. I'll check it again tomorrow.

This is still happening in the latest 2.80 build available on buildbot: version: 2.80 (sub 74), branch: master, commit date: 2019-06-19 18:29, hash: rBd30f72dfd8ac

I should clarify that image.view_zoom *does* work correctly, the bug is that view2d.zoom should either work in the UV editor- or not work at all. Right now the operator is allowed to execute, and correctly displays the tooltip- but does not function.

No worries, thanks for taking another look!

In T59978#590863, @Sebastian Parborg (zeddb) wrote:

This is sadly how clipping values work. Small clipping values will produce errors. There is no getting around that.

It's ten lines of code.. is there really nobody who can review this? It's been sitting in limbo for two and a half years. This would be very useful for addon developers....

yeah this behavior is just bizarre. are any other modal tools affected by this, or is it just Inset?