We Keep Coding

SpaceMouse Compact not working with js Gamepad api in Chrome on Ubuntu

As the title suggests I have a problem with using SpaceMouse in Chrome on Ubuntu. On Windows 10 it works fine. I've tried installing 3DxWare 10 and spacenavd but it still does not work.
It is worth mentioning that the mouse works with Gazebo perfectly fine so it must be a problem with Chrome. Is there some flag in Chrome or additional software to make the SpaceMouse compatible with Gamepad api in javascript?

Short answer: If your SpaceMouse isn't working with Gamepad API on Chrome for Linux, try relabsd.
Long answer: SpaceMouse is close enough to a gamepad that it sometimes works but sometimes doesn't. It would be nice if it worked, but getting it to work reliably in Gamepad API across all platforms is non-trivial and that kind of effort is better spent supporting real gamepads.
For this specific issue, the problem is how the device describes its inputs. Each input has a flag indicating whether the input is absolute (with a defined minimum and maximum value) or relative (meaning each input must be compared with the previous value). Absolute inputs are used for things like joysticks and touchscreen touch points while relative inputs are used for things like optical mice and trackpad movements.
Some SpaceMouse devices describe their axis inputs as relative, some as absolute. When it's an absolute axis, Chrome can fetch the bounds information and use it to normalize the axis to the range [-1,+1] as required by the Gamepad API. When it's a relative axis, bounds information is not available and the axis can't be normalized reliably.
SpaceMouse axes always behave like absolute axes, it's a bug when they're defined as relative. There's a third-party tool for mapping SpaceMouse relative axes to absolute axes, I haven't tested it but from the description it sounds like it does what you need:
https://github.com/nsensfel/relabsd
Some SpaceMouse devices (like SpaceMouse Wireless) report absolute axes and work with Gamepad API.

HTML5 Device Orientation - reliable compass implementation?

I am working on a mobile web project that needs to know the compass direction the user's device is pointing. It's incredibly simple right now, but here's what I have:
var updateDirection = function (evt) {
$("#direction").val(evt.alpha);
};
window.addEventListener("deviceorientation", updateDirection);
Based on what I've researched so far, the alpha channel of the event should be the compass position. However, I've observed (and read) that there are a wide variety of implementations based on OS and browser.
On my HTC smartphone, in Chrome or the default Android browser, I only get a reasonable reading (0 degrees = North, 90 = East, so on) when I hold the phone perfectly vertical in a "selfie" position. Any angle to the phone throws readings quite far off.
On my Surface Pro using Chrome, I can't get a reading greater than about 50.
On my Surface Pro using Edge, I get very reasonable readings, but only when I hold the device horizontal, as if it was laying on a table.
It seems likely that people have achieved getting the compass direction in a mobile browser regardless of device. Is there some library I can use to do this? Or is it necessary to simply code for many different specific scenarios, like this example, which also didn't work for all the devices listed:
Device Orientation Events

Is that really necessary for you to use javascript to find out orientation?
You could possibly achieve the same result with CSS media queries

How to force hardcoded value of JavaScript screen.width?

I am using a web application that wants to be used full screen. My screen is so wide that the application is nearly unusable full screen. More to the point, the application does deserve that much real estate. I am willing to give it ~1/3 of the width and I do useful work in the other 2/3.
I am convinced that this application uses JavaScript's screen.width to set the size of it's GUI bits. So, I am looking for a way to have my tool (my browser, for example FireFox) return a value of my choosing. Ideally, the same as window.width().
Maybe I would enable such a feature for specific URLs. More likely, I would apply this to everything.
Can this be done as an "extension"? If I need to, I can get the code to FireFox and put the feature I want in there.
What about Chrome?

You can always zoom in with ctrl + scroll. That lowers your window width.

IE11 on Microsoft Surface Javascript Range returns empty / invalid

I have an application that displays text, and when the text is clicked, determines the word clicked and fires an event containing that information. The word detection is performed via JavaScript Selection - Range objects. This works perfectly in all desktop browsers, as well as the Nexus 7 and iPad. On the MS Surface however, the range returned is invalid. Where the other browsers can return a valid node for the range endpoint(s), on the surface there is only an blank space, and an offset of 0 - both of which are inaccurate.
The tools I am using:
GWT
Rangy (JS Selection/Range library)
GWT-Selection with the same results.
Again, in other browsers / devices, rangy.getSelection().getRangeAt(0).inspect() returns node information and valid offsets, but on the Surface, I get nothing, just an empty inspect, similar to:
"[WrappedRange(" ":0, "":0)]"
(message not verbatim, copy pasting from the Surface being a pain)
Any ideas as to what may be going on / how I can fix it?

I was unable to fix the problem using the JS range, as I am for all other browsers. I had to implement a separate clicked text detection method specifically for the Surface. Thankfully, it was actually rather easy.
The Surface automatically selects the word you touch. My previous method, working with all other devices, expects an empty / collapsed selection, a cursor, and then expands from there. But for the Surface, I just have to get the selected text and clear the selection afterwards. It's actually easier - though it does mean I have to have two separate methods.

iOS6 Mobile Safari: Accuracy and update periods of geolocation.watchPosition

I'm facing a strange behavior on mobile Safari on iPhone4 and iPhone5 on iOS6.
What I want to do
Tracking the user's location in the browser with high accuracy, using
geolocation.watchPosition({ enableHighAccuracy: true, maximumAge: 0, callback })
Problem I'm facing
Normally, when the device is outside, under clear sky and moving, the accuracy und the update period of the GPS positions is very good.
The coords object passed to the callback has an accuracy of 5 meters, a correct heading value is given and when moving the callback gets fired at least every 500ms.
But: Sometimes the watched position never gets accurate, even though I test it under the same conditions (as far as possible).
Also, the update period is much longer, almost 30 seconds.
Basically, in this cases, the HTML geolocation is not useable for the accurate tracking of a position.
Observations
This seems to happen, when the GPS-Sensor is not on "Hot-Standby", I mean it was not used for some time (not sure how long) by another native app.
Reloading the page, re-allowing the GPS access and re-initializing the watchPosition does not change anything, still bad accuracy and slow updates.
Changing the options passed to watchPosition does not seem to do anything.
Manual fix 1:
Close Safari
Open another native app like Maps or GMaps
Determine the position in the native app
Open Safari
GPS position is immediately accurate, following position updates are fired again in 500ms periods and are very accurate as well (no reload needed).
Manual fix 2:
Close Safari
Open settings panel
Disable Wi-Fi
Open Safari
Again, problem fixed (without a reload)
Conclusion
When the problem occured, I looked into the coords object of the callback and detected the following:
Even though the passed location is far away from the real position of the device (> 1km), the accuracy passed is much smaller (very often at 165 meters). The heading is never given.
When WiFi on iPhone is disabled, there is a hint in the settings panel that says enabling WiFi will enhance the accuracy of determining your location (because of AGPS which is supported by a datase of geocoded WiFi networks). But as far as I can see this is not true if you want to use GPS in mobile safari. In fact, it does the opposite.
It seems to me that mobile safari does something like this to determine the location:
If GPS is already activated/in use on the device, it uses the GPS sensor (fast and accurate position updates)
If GPS wasn't active before and WiFi is enabled, the device only uses its WiFi database to get the location. (very slow updates, not accurate). It just updates from one WiFi location to another. You can see this very clearly e.g. if you drive on federal roads, as your location mostly get mapped to the next residential area.
Only if GPS wasn't active before and WiFi is disabled mobile safari will use the GPS to determine the location of the device (again, fast and accurate).
Question
Can anybody confirm my problem and my observations?
I worked with the geolocation in earlier iOS versions but never faced this problem before.
Is it a known bug for mobile safari, any chance that this will be fixed? Or am I just missing a better configuration of the watchPosition to get better results?

A lot of people have described similar problems including myself. I have described my problems on page 5 and onwards (as alstorp) in this discussion https://discussions.apple.com/thread/4313850?start=45&tstart=0
Read and see if it matches your problem.
The problem is that, as far as I know, Apple has not confirmed this. Are they working on fixing it? Is it really on their side? Is it really a bug? Therefore we do not know when/if it will be fixed...
Is there anyone out there that does NOT have problem with browser based geolocation in iOS 6? (even after multiple tests in different situations).
Have you tested your fixes extensively? My experience is that this type of fixes helps in some cases but not all the time (or for long periods). It would be really interesting if they work reliably for you...
(also check IOS6 geolocation watchPosition Callbacks fail
iOS 6 breaks GeoLocation in webapps (apple-mobile-web-app-capable) )

Can anybody confirm my problem and my observations? I worked with the geolocation in earlier iOS versions but never faced this problem before.
I tried watchPosition(onGeoSuccess,onGeoFail,{enableHighAccuracy:true}); in my web app using my iPhone (iOS 7.0.2).
With WiFi on accuracy was really bad, sometimes a mile off. With WiFi off accuracy was near perfect, with an occasional discrepancy of a couple hundred feet.
I have yet to test to see if helps to leave the GPS running between capture points, or if it's better to leave it off until you're at the next capture point and let the watchPosition() function settle.