Cannot reproduce it on linux either here (debian testing 64), so assuming it’s OSX-specific…

Just tried disabling Continuous Grab, but the result was still the same.
Here are the settings I have for mouse input:

Just tried booting up in safe mode to see if any programs I have could be causing an issue, but the issue is still there

Hmm, okay, next thing I'd try is lunching Blender from terminal using --factory-startup argument so we can be sure it's not a configuration issue.

It looks like I had already changed my default layout because when I did a factory startup, it just wouldn't work at all (not even in Default layout)

I don't know if this may be related to the issue, but on my Windows 10 Desktop, the feature only works if I press shift + F without moving the mouse. If I am moving the mouse while trying to go into fly mode, I will have the same issue as on my mac

same problem here, i'm using blender 2.75 (c27589e)
running blender on mac os x 10.9.5
I really need to fix this : /
any help ?

I just ran into this too. Mouselook broke in Camera Fly Mode. It was working and then suddenly a setting got corrupted and it stopped. Relaunching Blender didn't fix it. Only doing a "Load Factory Settings" resolved it. In case it helps here are the Preferences I modified today between the time it was working and the time it stopped working:

Input
Walk Speed: 33
Speed Factor: 5

Interface
View Manipulation:
Cursor Depth [ON]
Auto Depth [ON]
Global Pivot [OFF]

I enabled and disabled these in various combinations when trying to get the view to rotate how I wanted, and to get Fly Mode to be fast enough when traversing vast distances. These are the values I settled on, but I tried others in between. Changing only these settings back to the way they were before did not resolve the problem.

Another observation I made in the broken state is that doing a MMB-click while moving the mouse triggers the Teleport function. I wonder if an input conflict occurred when I tried to use MMB to look around (as one would normally in the 3D Viewport) while I was in Fly Mode.

As I'm typing up this bug report I'm troubleshooting and just discovered some new info:

It gets stranger... After encountering this problem first on a MacBook Pro (2015, running Yosemite) I then tried this on an older MacBook Air (2011, running Snow Leopard). The result on the Air was that I managed to get the Fly Mode control configuration screwed up there too, but instead of mouselook breaking this time it was the WASD keys that lost functionality. So on one machine I can move but can't look, and on another I can look, but not move. It's almost comical.

And yet more new info:

Before I tested this on my second machine I backed up my 2.75 folder inside ~/Library/Application Support/Blender/ so after I broke it the second time, I quit Blender, replaced the corrupt 2.75 folder with the backup I had made, relaunched, and now it's working again. Hopefully someone can replicate the bug and do a bit comparison on a corrupt 2.75 folder against a working one and pinpoint the cause.

Wait wait wait... my conclusion was wrong! Everything I posted above about replacing the settings folder fixing it is a lie!

Not being able to move using the WASD keys... turns out that's unrelated, and not a bug - just I slowed movement to a halt by scrolling down too far, while trying out various things to reproduce the bug. Restarting Blender would have fixed it even if I hadn't replaced the 2.75 folder.

That said, my experience is different from Jose's in that "Load Factory Settings" did fix it... in the default .blend, but not in my .blend. Furthermore I have an older incremental save in which mouselook still works!
Based on that, I now believe it to be a problem that can occur locally in the .blend.

Jose, can you load factory settings again and try flying in the default .blend? If it works there but not in your project .blend we will be able to verify we're experiencing the same symptoms.

Hello Seth,

I don't believe we're having the same problem. Mine seems to be more of a layout problem as yours seems to be a corrupted .blend file or setting. I just tried loading factory default in the startup blend file, but the camera would not work until I went into full screen mode by pressing shift + space. My problem doesn't seem to get fixed by reinstalling blender as I have tried that as well in the past. It is weird, however, how if I don't load factory defaults the camera only works with a certain layout configuration, but when I load factory defaults the camera only works when I go into full screen mode on the 3D view.

I'm on a rMBP with OS X 10.11 Beta 4 using the latest build from repo (f979115) and I also have this issue (no mouse control in fly and walk mode). I tried restoring factory settings to no success. Then I renamed the 2.75 folder in Application Support. Still no use. The only way I can make mouse control work is when entering fullscreen mode (alt+F11). Also during testing in fly mode I managed to loose all input focus with Blender reacting to no input at all. The only way was to open Mission Control and killing Blender. This is not good.

In fullscreen mode I noticed a separate issue: lots of tearing. It seams VSync is disabled in fullscreen mode. There is no tearing in window mode. Also the frame rate seams to be limited to 30 Hz. Weirdly the tearing consistently occurs in the vertical center. This can be made visible by setting the frame rate in the rendering panel to 60 fps and start animation playback (alt+a). In window mode the frame rate is limited to 60 Hz (my screen only supports 60 Hz). May I open another task for this issue?

Then I tested Blender 2.74 and mouse control in window mode works as it supposed to. To me it seams the root cause might be some mouse warping/grabbing issue in window mode introduced in 2.75.

Edit: Forgot to mention: launching blender with --factory-startup also didn't help.

This is a really elusive problem. Each time I thought I knew what was going on, it turned out to seem to be caused by something else. By the end of the day yesterday the .blend I had initially had the problem in was mysteriously working again, but when I would create a new file the problem would occur in the brand new files.

I'll experiment a little more and see if I can find out anything else.

Thanks for the feedback Jose.
Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug?

In T45771#329324, @Seth L. (quantumanomaly) wrote:

Fabio, I'm not sure what you mean about tearing and FPS. Are we talking about the same bug?

Sorry, no. That part was just an observation related to another issue.

I have yet to find a blend file which is actually working in window mode. Maybe could you attach a working one? Thanks.

@Jose Mayi (xDarkProdigy), are you using http://smoothmouse.com ? - this is known to have problems.

developer note, walk-mode uses mouse warping, even when continuous-grab is disabled.

Tested on OSX 10.9.5 (Macbook Pro), and fly mode worked fine - with both a mouse and trackpad.

In T45771#330426, @Campbell Barton (campbellbarton) wrote:

@Jose Mayi (xDarkProdigy), are you using http://smoothmouse.com ? - this is known to have problems.

developer note, walk-mode uses mouse warping, even when continuous-grab is disabled.

No. I don't think the problem could be another application because I made sure no startup item is running, just to verify that other programs were not conflicting....and like I said before, this was working prior to 2.75

I was having the same problem using a bit of software called MagicPrefs that adds some functionality to the Mac book pro track pad.

With magicPrefs open, i can use the mouse in Fly mode.
If i close the software i can use the mouse in Fly mode.

strangely though, it only affects 2.75, if i run 2.74, or 2.73 with magicPrefs enabled, the mouse still works in fly mode.

@Fabio Arnold (donfabio) Sorry, but posting a .blend won't help for this one. It seems to be a UI issue. Luckily we have some new info on it, and a lead on a resolution!
See this: http://blender.stackexchange.com/questions/38147/os-x-fly-mode-wont-respond-to-mouse-movements/

Excerpt:
Oh I found the problem! The Menu Bar above the timeline that lists the options "View", "Select", "Add", and "Object" was set too high by default-- the fly mode wasn't reading my mouse movements because they were outside the menu's navigation.

First I tried rearranging the layout a bit as some of you have suggested and I was indeed lucky for the first time. I got working mouse control in fullscreen with all other editors hidden except for view3d.
I found it weird that it only works in fullscreen mode and I noticed since I have my dock hidden on the left side of my screen the blender window was slightly displaced to the right by a few pixel. Moving the dock to the bottom of my screen I actually got working mouse control in windowed mode with the limitation of not being able to look down.

Then I decided to make a quick investigation using git diff v2.74..HEAD editors/space_view3d/view3d_walk.c to see what's changed since 2.74 (GHOST_SystemCocoa.mm and wm_window.c haven't changed much regarding mouse warping) and a lot of #ifdef USE_TABLET_SUPPORT has been added. So simply putting a #undef USE_TABLET_SUPPORT after #define USE_TABLET_SUPPORT in view3d_walk.c:63 restored old, working 2.74 behavior. So it looks like there's a problem with the tablet support code.

So that's a work around for now...

Currently we rely on being able to move the cursor to an exact location. Somehow on some OSX systems, the mouse position isn't set exactly as requested.

If its some off-by-one error, we could just not be as strict for OSX, though would like to know whats going on still, since that would be a workaround for an error in GHOST.

The error is likely in WM_cursor_warp or (GHOST_ClientToScreen, GHOST_SetCursorPosition).

@Fabio Arnold (donfabio)

Could you try these, running Blender inside a terminal.

• Running Blender with the --no-native-pixels argument.
• Could you apply this patch P259, and see the cursor coordinates after calling warp?

Regarding the patch: "FOUND!!!" isn't output but
wanted: (1015, 801)
got: (1014, 800)
is.
So obviously an off by one error.

When running with --no-native-pixels FOUND!!! is output and mouse control is working.

@Fabio Arnold (donfabio), thanks for testing, the problem is with WM_cursor_warp on OSX with retina,
Its rounding down odd numbers.

Will commit a fix shortly.

Awesome, thanks! :D