There seems to be a bug in the latest version of Firefox when trying to retrieve the absolute position of a field within Blockly.
I am building a custom field that works a somewhat like the text input field. I need to get the absolute position of the field in the window, which I can get by calling
element.getAbsoluteXY_()
this is working fine on Safari, chrome and even IE, and the older versions of Firefox. But it seems broken (unless I made a non trivial mistake) in the latest Firefox.
Context : I am superimposing a text editor on a field, which works well and gives the impression that a block contains an editor.
Did someone step into this problem (bug ?)
Damir
Related
Above is the image from netbeans terminal window. I want to use it to check the version of nodeJS.
Problem is when i click on the computer icon(single) to use the terminal so I can type it just refresh.
It becomes like above then after 1 sec returns to original state. I cant type anything on it
You must cgwin in order to resolve your issue here is link cgwin
I was writing some HTML in Sublime Text 2 and I noticed that the auto complete feature was no longer working. Just so we're clear, I'm not referring to the dropdown menu that suggests elements but rather the tag completion. Normally what happens is if I were to type an opening tag all I'd have to do is type the beginning of the closing tag and it would auto complete the tag which obviously saved a lot of time but now it's not working for some reason. I do have package control installed along with quite a few extensions but I heard that this feature is actually built in. I deleted ST2 off my computer and re-downloaded it, and it still isn't working so I'm not sure what else to try.
Is this feature really a default feature in Sublime Text 2? If so, why wasn't it working when I re-installed Sublime Text 2?
I'm on a Mac and I'm running Yosemite.
Thank you for reading.
Installed Sublime Text 3 and it works again.
I am developing a Chrome Packaged app that has a webview in it. The problem is that I cannot type any sort of accented character (such as é, ç, ê) in a text input that is inside the webview. When I try to type é, for instance, I only get e in the text field. Strangely I can copy and paste accented characters into the webview text field without a problem.
Text inputs that are outside the webview work ok. This issue only seems to happen when running the packaged app on Mac OSX (It works fine on Windows). Other official sample apps that use webviews also have the same issue.
I have already checked if UTF-8 is being used by both the app and the webview itself, and it is.
Any idea of what might be happening?
Like lazyboy commented, this has been fixed since Chrome 34. It was actually a bug in previous versions of Chrome.
Our web application is designed such that the text transform is picked from CSS.
There are multiple links on a webpage; hence i will take example of a Next link.
When i hover the mouse over Next link in FF, it shows the below code:
_click(_link("Next"));
Similarly when i hover the mouse over the same link in Chrome, it shows the below code:
_click(_link("NEXT"));
When the script is recorded in FF and executed in chrome, it fails at the location because "Next" link is unavailable. This is one example of a link and there are multiple links and multiple pages. For this scenario, do i need to verify the text for each link or is there a universal way i.e. toLowercase method that can help me.
Thanks.
As Kshitij pointed out, you can get this working by using a regular expression as your accessor... but you might also check the Alternatives pulldown in the Controller. Perhaps there's an alternative accessor that is better suited for both browsers.
I think, the question should be how can Sahi identify the element with text by ignoring the case-sensitivity.
Any tool can only record the attributes which is available on the browser at that time.
You can use the following code to achieve the functionality:
_click(_link("/Next/i"));
To debug extensions, Chrome used to have a "Inspect popup" menu option available when right clicking the extension icon (top right in the browser). I believe this options was recently removed (possibly with the latest Chrome version 20, which I am using) .
The debug console can still be activated by right clicking any element in the extension popup and selecting "Inspect element". The problem I am experiencing however is that whenever I now have the debug console open, typing into form elements in the popup does not work. Even though the form element seems to have the focus (it has a blinking cursor active), all input typed goes straight to the debug console.
Update: It seems focus is not specifically to the debug console, but to whichever window is below. It's like the extension window is a "stay on top" window, without capturing any input.
Update: 2012-07-24: Updated to 22.0.1215.0 (Official Build 147830) dev and the bug is still there. But yay, Youtube full screen now suddenly works on my dual screen system!
Update 2012-05-09: Upgraded from 20.0.1123 to 20.0.1130.1 dev on Linux x64 (Ubuntu 12.04). Problem still there, and makes debugging extensions a lot harder than needs be. Also confirmed behaviour on older Chrome release (20.0.1105.0). Oh well, maybe it's just me...
Update 2012-05-09 2: Assuming this is a bug, consider adding a background page to your popup and log to that page's console instead until bug gets fixed. At least that makes my life easier for now.
Update: 2012-10-19: As omri writes (and points to), the Inspect Popup option is on it's way to be put back into Chrome, which will hopefully solve this problem (finally).
Could anybody confirm/deny this behavior, and/or suggest possible workarounds?
Open the popup
Right click the popup window and inspect.
Its going to be re-added to chrome
http://code.google.com/p/chromium/issues/detail?id=143349
Update: Un-accepting answer as another user confirmed this behaviour for OSX, so at least it will appear as unsolved on the radar, although there's probably a bug tracker somewhere where this needs to be posted.
This bug is still present on google-chrome-beta (Version 20.0.1132.34 beta). I'm guessing that this has to do with window and popup handling on X11 generally, and is obviously not a high priority bug since it's remained this way for quite a few releases. Closing question.
I am seeing the missing "Inspect Popup" option on right click but, I can edit/enter text in the form fields.
I am wondering if you are having an unrelated problem? If you are using or updating to the new 2.0 Extension Manifest you can encounter issues where inline javascript in the popup fails to fire any longer because of the addition of the content_security_policy defaults. Basically this prevents script injection but also seems to kill all JS in your popup. There are ways around this by changing the way events are handeled in your popup or by changing the default policy. Here's a link to the doc on this: http://code.google.com/chrome/extensions/contentSecurityPolicy.html
This is just a guess because I don't know what's going on in your code but I saw similar things while upgrading my extension recently.
Just upgraded to 22.0.1221.1 (Official Build 149058) dev and the problem seems to have been solved, albeit with a workaround. The old way of right clicking in the popup window and selecting "Inspect Element" to start up the console still grabs all input as originally reported.
However, it seems by right clicking the popup icon, the old "Inspect Popup" seems to be back, and when this is used it does not seem to grab input from the open popup window itself.