I'm attempting to change the mouse cursor programmatically using JS/CSS, and here's my problem: it seems that Chrome will *force the pointer back to the default pointer no matter what one sets it to.
Here's a minimal example that illustrates the problem:
<html>
<head>
<style type="text/css">
div#mouse_test
{
cursor: crosshair;
}
</style>
<body>
<div id="mouse_test">Here is a small div</div>
</body>
</html>
When I view the above example in Firefox, it works as expected, in that mousing over the text of the div changes the cursor to a crosshair.
When I view it in Chrome, though, the cursor changes to a crosshair then (after about a second) changes back to the default pointer.
Does anyone have any insights? Is it true that Chrome forces the default pointer? If so, is there any way to get around that?
Any help would be greatly appreciated. Thanks!
FIXED
Turns out that restarting my browser fixed the issue. Still odd, though, as I was seeing the problem behavior on *every page that changed the mouse cursor- the one I was working on, as well as several pages with CSS cursor examples that I was viewing. I was working with JS timers to set the cursor, so it's possible that one of those was hanging around in the background. Still odd, since the behavior was completely consistent across multiple tabs.
Big thanks to the Stack Overflow community for the quick and helpful responses :)
That doesn't happen for me in Chrome 9.
So I don't believe it forces the pointer.
Restart your browser and try again (sometimes my cursor flickers between the pointer and normal).
Related
So I have developed a basic website which runs on old feature phones as well as smartphones. Now on a feature phone, at times, a mouse pointer appears via which it makes it easier for the user to scroll and select certain options on the website. I have tried replicating the process but I have been unable to do so. It always happens randomly. I would love to know what I can add to my code to get the mouse pointer permanently active. Keep in mind I cant use Javascript as the feature phone I am testing on does not have JS and this is also the case for most of my users.
You just need to use cursor: pointer in the CSS for whichever element you want to display the cursor for. For the whole document, that would be:
body {
cursor: pointer;
}
Hope this helps!
I have just now sended the following message to google chrome developer:
Chrome version: 54.0.2840.59 m
As you know, when debugging a web page with javascript, the Chrome
debugger allows to pause the execution of the code on breakpoints. In
this moment is possible to move the mouse onto a variable to see what
value has in: when the mouse is on the variable chrome code
inspector/debugger shows a little tip showing the variable value.
The problem is that such little bubble tip sometimes is toooo little
and it is not possible to see the content.
Please correct its size (make it resizable) to make possible to read
its content or it isn't useful.
Thanks
Anyone else has noticed the same issue?
Someone has solved it?
Edits
Before the last update was working perfectly (or at least I didn't see anything wrong in its behavior!), but now the following image shows the issue that sometimes happens:
As shown into the above img, part of the bubble tip content is shown, part is hidden, and it is not possible to scroll the bubble tip neither up|down nor left|right: scrollbars are greyed. Sometimes scrollbars don't appear at all.
You can scroll the tool tip as per the animation below:
A possible workaround could be adding the variable to the watch list:
Procedure:
right click on the variable
Into right click menu click on "Add selected text to watches"
This allows to keep an eye on the watchlisted var contents, even if they hidden into the bubble tip.
It is not completely handy, but works.
I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I've built a simple proof-of concept, here:
http://kentbrewster.com/android-scroller/scroller.html
... which works like a charm. When I attempt to add an INPUT tag to my header, however, I hit trouble. On focus, every device I've tried so far clones the INPUT tag, gives it an infinite Z-index, and repaints it on top of the old tag. The clone is in roughly the right position, but most of its parent's CSS (including, of course, position:fixed) is ignored. The cloned INPUT tag is the wrong size and shape, and when I scroll the body of the page, it scrolls up and off the screen.
Once it's off screen, hilarity ensues. Sometimes the device will force the scrolling part of the body back down so the cloned blank is back in view; sometimes the keyboard goes away even though the visible box seems to remain in focus; sometimes the keyboard cannot be dismissed even though the INPUT blank is clearly blurred. Here's an example you can run on your Android 2.2 device to see what's happening:
http://kentbrewster.com/android-input-style-bug/
Styling input:focus has not done the trick for me yet, nor have many different brute-force attempts to listen for focus() and blur() with JavaScript and do the right thing with focus and the keyboard.
Thanks very much for your help,
--Kent
This will probably not be resolved until Android switches to using Chrome for its WebView. The current Android browser creates an Android TextView on top of the page when an HTML input field is focussed. Apparently they don't style or position it correctly. You can see it go more wrong on pages that use contentEditable.
The current Chrome-for-Android implements the WebKit IME interface, so input fields are drawn by WebKit (and lose some of the niceties of the Android TextView on ICS) and shouldn't have issues like this.
The solution is to add:
input {
-webkit-user-modify: read-write-plaintext-only;
-webkit-tap-highlight-color: rgba(255,255,255,0);
}
in your css.
You might be able to solve it by using a bug in Android: http://code.google.com/p/android/issues/detail?id=14295.
That is, don't display the input field right away. Instead, display an overlay div which listens on click and hides itself and shows the hidden input, and give the input focus. This somehow prevents Android from using the wierd input that gets placed on top of everything, and is instead using the browsers input field which you can style any way you want.
As you'll note in the bug raport though, this doesn't work with input[type="number"]...
HELP, this is a very unique problem and I can't for the life of me figure it out.
My flash content is overlapping the HTML above it.
This only happens if I've just launched IE after being restarted and goes away once I refresh the page. I even added a jQuery $(document).ready function that sets a margin between the html and the flash content to add 1px of space when the page is loaded. It's so hard to figure out, because once I refresh the page, it goes away.
Any input GREATLY appreciated.
Here is the site.
http://www.californiaremodels.com
(This only happens in IE)
here is a screen shot of the problem.
########### SOLVED ###################### SOLVED
I set the flash output as a javascript var (actually json_encoded PHP output) and on document load inserted the object into the "flashContent" div with the jQuery.(document).ready event.
Thank you to Andy Shellam!!
Have you tried loading your flash content using jQuery? I.e. set your div width/height in your HTML with a "this requires javascript/flash" placeholder, then have jQuery load the OBJECT into the div on page load. This way cures IE7's annoying "click here to activate this control" issue - may be a similar issue.
It may be due to the fact that you're floating that DIV that holds the flash content. It shouldn't matter, but sometimes IE gets hinky about such things. Try taking off the float and see if that cures the problem. If it does, create a non-floating workaround.
looks like it is the -4px of margin top you have that is creating the problem
I have the following CSS that hides the mouse cursor for anything on the web page. It works perfectly in Firefox, but in IE and Chrome, it doesn't work.
html {
cursor: none;
}
In Chrome, I always see the mouse pointer. In IE, however, I see whatever cursor was last 'active' when it entered the screen. Presumably it's keeping the last selection instead of removing it.
This property cursor:none; isn't part of the standard
See here w3c cursor CSS properties.
You might want to look into hiding it with Javascript or JQuery.
Also, look at blank cursor files here.
And one last link to an ajax solution.
Chrome has had this issue since it was built, there have been reports sent to the people at Chromium, and I assume they are working on it.
Also, don't trust that anything would work in IE. Ever. :P
I had the same problem in these days and found a good solution to hide the pointer in Google Chrome.
This is the W3C definition of url property:
A comma separated of URLs to custom
cursors. Note: Always specify a
generic cursor at the end of the list,
in case none of the URL-defined
cursors can be used
So, you can define a url to not completely transparent image, followed by the default pointer:
cursor: url(img/almost_transparent.png), default;
If you choose a totally transparent png, Chrome will display a black rectangle instead, but if you choose a png with at least 1px not transparent it will work, and nobody will notice the pointer.
Finding something that works across browsers is a pain.
The code below works on Chrome, IE, and Firefox. IE likes .cur files, Chrome likes the embedded png, and some browsers actually respect the none :)
div {
cursor: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAZdEVYdFNvZnR3YXJlAFBhaW50Lk5FVCB2My41LjbQg61aAAAADUlEQVQYV2P4//8/IwAI/QL/+TZZdwAAAABJRU5ErkJggg=='),
url(images/blank.cur),
none;
}
So the best way to deal with this now is the pointer lock api.
https://developer.mozilla.org/en-US/docs/WebAPI/Pointer_Lock
It'll hide the mouse cursor, but give you access to the data about mouse movement as well.
In css: * { cursor: url(cursor.png), none !important }
Use a hidden applet with the java.awt.robot class to move the cursor off the sreen. Say the very lower left corner.