These are both no bugs.
The first one is the effect of the setting "Auto Perspective" in Preferences > Navigation > Orbit & Pan.
The second one is the effect of "Clip Start" value being too high in your case. Go to the View Panel in 3D Viewport Sidebar ("N") and set Clip Start to 0.001 instead of 0.1. Then your cube will be visible even when you are zoomed in that far as in your case.

Hm, can't reproduce either anymore. weird...

@Brecht Van Lommel (brecht) thanks so much for fixing! this makes so many things so much easier now! :)

Hehe, yeah, with Blender's development speed you better compile immediately after finding a bug. It might already be fixed! :)

Thanks for the report, but if I am not mistaken this was fixed a few days ago: https://developer.blender.org/rB683e64247f060acbb8b9ba9178e7555dc57aa10b
@Dirk (d-egg), try again with a recent build.

@Tim Stullich (tstullich) so sorry to have put you on this, I really thought this would be an easy one , especially because it works fine in preview rendering.... I better shut up next time :)

Yep, can confirm that, happens here as well.
Sounds very similar to T62320 and T62317.

I can confirm that.
In the scene below there are 2 cameras. The selected one (not the one you are looking through) has the
camera.data.shift_y value set to -1. If you hit CTRL+0 and make it the active viewport camera you see the grid changing. But the cycles rendered viewport only updates when you click anywhere.

Yep, crash confirmed.

Project Format sounds really weird. I wouldn't expect the render dimensions behind it. I would prefer Output Size.

I'm not sure, this just adds more space taken by UI organization elements? Sure, this is just my personal preference, and animators might disagree, but I don't see myself delibarately closing the Render Size Panel and only leaving Time open.

@Bastien Montagne (mont29) Don't worry, I find it very useful and was glad you brought it back today. I was missing it when the other two duplicate options were added. Though those are also very useful of course! :)

Same problem in the Clip Editor. If the Menu could at least be moved around it would help a lot.

+1 from me!
For people who mostly render stills this would be an improvement. I could move the Time Panel to the very bottom, making output panels cleaner for me.

Duplicating should definitely be possible, but wouldn't mind holding a modifier key for it. But yeah, consistency is important.

It's because the Camera is your active object currently. And the camera does not have material properties. Select the cube and you will see the material slot again.

Please provide a blendfile that demonstrates the bug then.

To me this doesnt sound like a bug, but like normal behavior.
The origin of a collection is always at 0,0,0. If you want to have the origin of the collection be at the same place as the object in your collection, you have to select the Cube, snap the cursor to the origin of the cursor and then go to the Collections Panel in object properties and choose "Set Offset from Cursor" in the little dropdown menu to the right.
If I try this here the collections work perfectly normal, the same way like in 2.79, so I would consider this not a bug.

Please do not use the Bug Tracker as support platform for user questions.
Apart from that, see here: https://www.blender.org/about/license/

Wow, that's interesting.
So with your file I am able to reprocuce it. I would guess that somehow the Mapping nodes in your blendfile are broken.
I opened a new file with factory settings, no Node Wrangler, and appended the material "Mineral.001" from your blendfile. When I assign that material to the default cube the Mapping nodes show the same behavior.
Speaking of weird behaviors:
On the Mapping node 'Mapping.008', the bottom one, I cannot even change the mapping type. Clicking on 'Vector', 'Normal' or 'Texture' does nothing.
I am not sure if that bounts as a general bug, or if somehow just the nodes in your material are broken, or if there is some other weirdness is going on.
Because with a new file I cannot reproduce this behavior, with and without Node Wrangler.

Lol, you're welcome :D

I think this is because Filmic is now the default View Transform, which is why the footage has to be converted for display first. If you change the View Transform from "Filmic" to "Default", it should play fast again.

I cannot reproduce that. It works as expected here.

This is not a bug, it's more a little inconsistency in UI functionality.
Try the Gizmo toggle at the very top, it works the same way.
Codewise the difference or Gizmo and Motion Tracking to the other checkboxes is that the related settings are being toggled like this:

Thanks for the image.
I wouldn't say this is a bug, more a design question.
The little dotted "grabbers", which you find at the right of every panel, also goes under the panel title.
However, the presets menu acts more like a functional button, so maybe they should cut off the panel title text, like for example checkboxes do? What do you think, @William Reynish (billreynish) and @Brecht Van Lommel (brecht)?

Yes, a picture would be nice because currently I don't know what you mean.

I can confirm this behavior on elementaryOS 0.4.1, GTX980. I tested with a blender version from a few days ago, where it loaded instantly, then compiled with current master, and it takes at least over a minute. Too bad I didn't note the hash of the working version though...

Why wouldn't I be? It works just fine in 2.79.
Usecase:
Usually I have my main scene with main geometry for the building etc., which instances objects like furniture and props from single files.
Now I want to have a second file with a variation of that scene, but some props should be linked from the first scene to the second scene, so that those objects are always in sync and share the same position, rotation etc. . It should actually be not a big deal to do that.

Hi,
this is before:

I think this would be a very welcome addition!
Actually I was expecting the dropdown menu in the 3d Viewport to be per viewport by default.
Overlays, Object Visibilty and Shading are per viewport, so it would only be logical to make the collections dropdown menu be per viewport as well. Or at least add the option to override it. I agree with @William Reynish (billreynish) that currently it is just redundant and adds no extra funcionality.

I think that is because the script you are using is not actually using an Operator, so there is no Last Operator to repeat.
Try another Template instead: operator_mesh_add.py
When you hit Alt-P it will create a Cube already. But try to launch the Operator from 3d View by opening the Search Menu and typing "Add Box". After you hit Enter you will see the Last Operator box.
So no bug here. :)

Yeah, was my own build. I deleted the bin folder as you suggested, rebuilt and indeed - that fixed it! Thanks a lot!

It happens every time. Also with just 1 GPU. Here's the log:

1. Blender 2.80 (sub 44), Commit date: 2019-02-12 14:57, Hash 43139bf8b4cd

I have updated the diff. Loc and Affine don't use an icon anymore.
Here's the diff: https://developer.blender.org/D4284

I would like to move forward with the tracking pies. There are probably some things that can be improved and added, but it would be nice if they could be implemented now. I have updated both space_clip.py and blender_default.py in order to have them not as separated addon and have the correct key mappings.
As discussed with @William Reynish (billreynish) a while ago the icons for Affine and Loc probably need their own icon...
Once the pies are implemented I would look into an updated Specials Menu ('W'). Maybe @Sean Kennedy (hype) has some suggestions for it?

I am pretty sure this works as intended. 2.80 has "Release Confirms" enabled by default in Preferences. Enable it in 2.79 and you have the same behavior. Or vice versa, if you disable "Release Confirms" you get the behevior you seem to be lookin for. Besides, you can always cancel the Action by pressing Escape. So, I don't see a downgrade really.

Sounds more like a duplicate of this one: https://developer.blender.org/T57770
And that has been resolved.
Please check if it still happens with latest builds.

Yes, I can reproduce this bug as well.
However, it seems kind of random. It is not always the same marker, which deletion causes a crash. Sometimes it is the marker that is already selected when you open the blendfile from BlenderBugReport.zip, sometimes I have to keep deleting and selecting markers until I get a crash. The crash can happen with markers from both, Camera and Object.
It is probably related to this bug, which was already reported a while ago: https://developer.blender.org/T58773

I can reproduce this as well. I open the tracking_test.blend file from above, select any Marker, hit X to delete: -> CRASH.
Here's the log from --debug-all: http://pasteall.org/1402918

I am not quite sure if this is really related, but since then I am getting a CMake Error:

This has been fixed, yes.
This one however is still open: https://developer.blender.org/D4020
:)

This sounds very much like an issue with colormanagement. In 2.80 the default view transform is Filmic. In order to display movie clips correctly the correct mapping has to be applied first. This happens during playback. So once the clip has been played back once, the movie was "converted" internally to the correct view transform. That's why playback is realtime the second time you play it.
You can also set View Transform in Color Management panel from "Filmic" to "Default". That should give you better playback performance right from the first play of the movie.
(Sidenote: "Default" is really not an adequate term anymore, since it isn't even the default setting! :)

My colleague just tested this on Windows10 with the most recent Blender 2.80 build.
While it does prefetch the footage, it does act a bit weird. The interface seems to freeze until the prefetching is done. Unlike in your case however the footage is in memory after prefetching is finished.
Even though the GUI is a bit unresponsive, we could still press the little X in the prefetching progress bar to cancel it. It works pretty much the same as on my Linux system. Our systems are quite good though (32GB, Hexacore). 4GB of system memory is far from ideal for motion tracking, so poor system performance might play a role in your case. Still, I can't really see a bug here.
However, responsiveness when caching movie files could definitely be improved. When prefetching image sequences the interface stays fully repsonsive here, and the way the progress bar is reporting the prefetching progress is more realtime and repsonive as well.
When 2.8 is more stable and there is a bit more time for polishing this might be something to look at, @Sergey Sharybin (sergey)?

Ah, good one. Maybe instead of Detect Features? This is not used so often...

Yeah, happens here as well (Linux, GTX980, Blender.280 ebfea8c).

Interesting. Would be nice if some other windows user could test this. At the very least I'll have my colleagues in the office test this on monday.

Removing shortcuts is fine, but I was looking for the Flip Normals command as well today and was surprised not to find it in neither Context nor Faces Menu. I think it's quite a common operation to be used in Edit Mode and I don't see a reason not to include it in Context or Faces Menu. What do you think about it, @William Reynish (billreynish)?

How much RAM do you have, and what's set in your User Preferences, in System>General>Memory Cache Limit? If you prefetch and watch your System's memory consumption, is your RAM filling up or not?

I don't see a bug here. It's true, Blender does become unresponsive for a moment, but that's just due to the prefetching of the movie file. Prefetching image sequences works smoother. At least on my system (Linux64bit) I cannot see a difference in prefetching between 2.80 and 2.79.

@Sean Kennedy (hype) You have probably tracked in way more programs than me, but at least in the handful of tracking programs I tried none of them had the same approach to super accurate supervised tracking like we have eihter. I think in Blender the single marker plays a more important role by itself than elsewhere, so I think it's fine if UI reflects that.

Ah indeed. Can only reproduce with mask points though as well, not with tracking markers.

I tried it with several configurations, but couldn't reproduce it. Toolshelf and Sidebar expanded or collapsed, floating panel expaneded or collapsed, fullscreen or not - I could not reproduce this bug in any case. I am on Linux though. Might be a Windows bug?

I am not sure about merging the track settings to just one panel. It would be a regression to 2.79, where we have those settings separated.

Flip is one of the most used buttons in the colorramp node, at least for me, so having that go into a submenu is not really an ideal solution.
Why not move the menu or icon for the even distribution thing between the two sliders below the actual colorramp? Those sliders are quite big, especially the position slider is larger than it really needs to be.

I have changed some of the shortcuts.
The Alt key is now being avoided, because on a Mac it is not as comfortable to reach as the shift-key.
So:
Tracking Pie: 'E'
Setup Marker: 'Shift + E'
Setup Display: 'Shift + D'
Setup Tracking Scene: 'Shift + W'
Solve: 'Shift + S'
I find these very comfortable to reach and execute.
Compared to the clip editor hotkeys in 2.79 we would sacrifice Shift+D, which was used for the 'Disable Marker' Hotkey.
However, that operator is in the Tracking Pies at the bottom, very easy to reach.
And the 'Show Disabled Markers' toggle is now at the bottom of the Setup Display Pie, so in the same position, hence very easy to remember.
Following that logic I think we can also remove the hotkey Alt+D, currently used for the "Show Disabled Markers" toggle.
And I would vote for having the tracking pies enabled by default.

Thanks a lot for the feedback!
I agree about the lacking feedback for a toggle in a pie menu possibly being an issue. However, I would like to keep most of them because it makes the workflow so much faster. And they still can be used in a gesture style interaction, contrary to some other pie menues from the community, where there are multiple entries pre pie-slot, something I consider opposite to the idea behind our pie menu implementation. But I'll have a look again and see if some can be replaced.
About hotkeys, well, the left side is pretty crowded. Q, W, A, S, R, D, X, C are all taken. I find combinations of Shift and E, W, S still very easy and comfortable to execute with the left hand. I was about to say the same about Alt+E as well, but I am typing this reply on my macbook, and there the Alt key is in a less comfy place. So I'll have a look at the keys again. :)