This has to be a programming question, relevant for stack-overflow, but there might be something I'm missing.
So, has anybody else observed this problem?
(This would be easily recreatable only to people who use multiple languages regularly.)
My problem is this: to swap between my two languages, I normally use the alt+shift shortcut. This works everywhere, for example it works in MS office, chrome and firefox, notepad, visual studio... it even works on the Microsoft Edge's search bar. However, when I am typing in an html element in Microsoft Edge in Windows 10, it doesn't.
Until now I have to either change the language from the taskbar, using the mouse (which is slow), or take the focus off the control, use the shortcut, and give the focus back to the control (which is slow but also annoying)
Anybody know to help me with this?
I'm interested in understanding what's wrong more than solving it, since I can always use another browser.
PS: If I was as frustrated as I am now, I would whine about how Microsoft manages to keep making things that everybody else has solved ages ago, difficult.
Related
I've been looking for an answer for a while now and I can't seem to find any reasons why this is an issue. I have various places in my style sheets where I use cursor: pointer for UI elements like buttons and links. The majority of the time it works as I expect, but occasionally they just don't want to work. I'd love to say I have a specific example in the style sheets that would ensure replication but that's been the issue. When it happens, it's not just for one element, it's for all of them. I've experienced this across the board with modern browsers and it seems to just be completely random which makes it hard to troubleshoot.
The only thing I've been able to confirm 100% is that if it does happen, I can open developer tools, then select an element to inspect that is supposed to have the cursor: pointer and the effect begins working everywhere again. I'm not sure what's going on here and it's driving me up the wall.
Is there any documentation surrounding this issue or something similar?
I experience it in localhost.
I haven't noticed it in production.
I haven't noticed it on JS Fiddle or Codepen when creating wireframes.
Is it a localhost issue? I've even thought it may be related to something I had done prior, but it happens even as I just navigate the site while debugging, sometimes it works on one page, but come back to the same page later in the session and it may not work anymore.
I know this one's tough and there's not a lot to go on. I don't usually make posts without code, but I'm just wondering if anyone else has experienced the same or a similar issue and resolved it.
I too have experienced this. It's actually not a code issue at all. I've found that the cursor: pointer bug you're experiencing is directly related to the Visual Studio 2017 (and newer) remote debugging browser window.
Solution
In Visual Studio, disable "Enable JavaScript Debugging for ASP.NET (Chrome & IE)".
At the top of your Visual Studio window, go to Debug -> Options. The highlighted item in the screenshow below must be unchecked:
This was a feature added in 2017, and while it helps with debugging JavaScript and TypeScript, it does so by launching a plain browser window ("remote debugger"); that is, no extensions, no bookmarks, no history, etc. The remote debugging browser window seems to have its fair share of bugs.
I saw this same behavior but not while debugging through visual studio. If I hit F12 to go to the Chrome dev tools, then click on an html element. The cursor goes to the style listed according to the style sheet.
I am currently using Netbeans IDE 7.4 to write some basic HTML code. Whenever I type a tag, it immediately highlights it, making it next to impossible to read until I click somewhere else. This is incredibly annoying. I have looked at all previous solutions, but for some reason they only work with Java and not HTML. Does anybody know how to fix this?
After ongoing bouts of frustration with the NetBeans highlighting, I finally figured out this was not so much of an issue of highlighting being turned on or off, but more an issue of how the highlighting is being rendered.
Turning highlighting off completely (as suggested above) has never been fully successful in my case in either NetBeans 8.x or 9.0 (I'm currently using 9.0), and the highlighting can seriously become so annoying in that it's too difficult to read the highlighted text, that it becomes a distraction and negatively impacts productivity.
Having determined that this is a question of rendering verses IDE functionality, the original answer is on target as far as modifying the Mark Occurrences styling in:
Tools > Options > Fonts & Colors > Syntax -> Mark Occurrences.
However, since I work in multiple projects of multiple types, I selected 'All Languages' in the drop-down, set the foreground and background colors to 'Inherited' (getting rid of the sickly yellow background (I'm using the Sublime Theme) and added Bold and Italic styling to the inherited font setting.
Now, no matter the project or the language, highlighting is still working as intended, but it's no longer an annoyance.
Hope this helps for others who have been likewise frustrated by this feature of NetBeans! It was getting to the point of almost driving me to another IDE.
The mark-occurrences color can be modified in Options->Fonts & Colors
-> Syntax, language: Java, Category: Mark Occurrences. To turn it off completely go to Options->Java code -> Mark Occurrences and
disable the first checkbox.
http://netbeans-org.1045718.n5.nabble.com/Turn-off-or-change-the-automatic-highlight-of-the-mark-occurrence-feature-td2949743.html
Try to change profile. That works for me.
Tools > Options > Fonts & Colors > profile.
Hope it will help.
In Netbeans 12.5, this is configurable in Tools|Options|Editor tab|Highlighting tab under Editor tab
I know it's not exactly the use for a browser one could expect, but it would be useful it there was a way to explore the DOM of a page (read/set values) and send commands (clicks, for example) with automation, not manually.
It could be with C, C#, even VBScript, for what I care, or DDE (but this seems to be a no), or using a third party extension... Anything could do.
The fact is that this way could be difficult, but precise. I could use AutoIt, for example, but it would blindly execute the script without really having the possibility of managing problems.
The browser has to be chrome. I don't have much hope, but I can still ask...
The obvious answer would be "make your own extension", but I'm trying to avoid that.
UPDATE
The "headless browser" thing seems nice, but in effect I need to use the interface by hand before leaving it to the automation, it should remain visible.
...Essentially because I need to activate an app, and I do it by hand, but I'm searching if there's another way.
EDIT
Yeah, it seems they are 'explorable' by url, so this shouldn't be a problem.
Not sure how helpful this may be but...
You could investigate Selenium, I am not sure as to how well Chrome is supported, according to the docs it is at least partially supported. You could perhaps use FireFox for full support...
The favorite seems to be Watir, then Selenium, then Watin.
Possibly I may need some other tool, but this part shoul be covered.
Thanks to Automating Chrome, Automating Firefox and Chrome browsers, and lee.
I've been doing a lot of testing in IE10 lately, and have recently ran into a very strange error.
Right after closing a jQuery UI dialog, IE10 opens up a cursor and allows the user type directly into the page. However, there are no inputs for them to be allowed to put things in, and from using Microsoft's F12 Developer tools, it seems that it is writing directly into the DOM -- an area that was a 'Text - Empty Text Node'. I have no idea where these nodes are coming from, or why the user can put text into one of them. I really have no code to show because it seems to be tied to nothing, and as I keep cutting away layers it still seems to be there.
Has anyone else ran into this? It seems to happen in IE9 as well. I'm at a loss here.
EDIT: In addition, I thought it may be helpful to say that I'm using jQuery datatables here.
Okay, so I have made some progress on this.
It turns out IE10 isn't writing data directly into the DOM -- instead, it dynamically created a text input, didn't recognize it, and then deletes it. You can type directly into it, but if you click off or focus on anything else, then it disappears and leaves completely.
I've still not diagnosed the source of the issue -- I know it only happens in IE, and may include datatables or jQuery UI. I tend to believe it's IE specific, because it's such a rare action and there's no trace of it anywhere else.
Hope this dialog helps someone else down the line. If you find a better answer, please post it!
Basically, something better than this:
<input type="file" name="myfile" size="50">
First of all, the browse button looks different on every browser. Unlike the submit button on a form, you have to come up with some hack-y way to style it.
Secondly, there's no progress indicator showing you how much of the file has uploaded. You usually have to implement some kind of client-side way to disable multiple submits (e.g. change the submit button to a disabled button showing "Form submitting... please wait.") or flash a giant warning.
Are there any good solutions to this that don't use Flash or Java?
Yaakov: That product looks to be exactly what I'm looking for, but the cost is $1000 and its specifically for ASP.NET. Are there any open source projects that cover the same or similar functionality?
File upload boxes is where we're currently at if you don't want to involve other technologies like Flash, Java or ActiveX.
With plain HTML you are pretty much limited to the experience you've described (no progress bar, double submits, etc). If you are willing to use some javascript, you can solve some of the problems by giving feedback that the upload is in progress and even showing the upload progress (it is a hack because you shouldn't have to do a full round-trip to the server and back, but at least it works).
If you are willing to use Flash (which is available pretty much anywhere and on many platforms), you can overcome pretty much all of these problems. A quick googling turned up two such components, both of them free and open source. I never used any of them, but they look good. BTW, Flash isn't without its problems either, for example when using the multi-file uploader for slide share, the browser kept constantly crashing on me :-(
Probably the best solution currently is to detect dynamically if the user has Flash, and if it's the case, give her the flash version of the uploader, while still making it possible to choose the basic HTML one.
HTH
You could have a look at the Fancy Upload script. Though it uses flash it still looks great.
The problem here is that the browsers specifically work to block anything that changes the basic file upload input control. You can't change it with javascript for instance.
The reason is security - if I could script it I could build a page that when you visited it sent me various files from your hard disk. Not nice.
There are various workarounds at the moment, but they're different between IE and FX (I don't know about Safari, Opera, etc).
Look at what http://www.gmail.com does in IE and FX when you attach something to an e-mail.
I want to see that rubbish "Browse" button - it tells me that I'm not letting anything unexpected in.
It is true, the file upload control is definitely behind the times. Hopefully this will be addressed in a future asp.net version.
Though it costs some money, I have found the Telerik upload control to have all of the functionality that you are looking for, including styling and progress updates (it also optimizes memory for large uploads).