I found that a map I created with href in the tooltip was not working today. After trying 3 browsers on my Mac and a re-boot, I switched to Linux and found the same thing.
So, I checked the Altair example that it was based on here:
https://altair-viz.github.io/gallery/scatter_href.html
And this also does not work for me. The Tooltip dialogue appears normally but the html link is not active.
I did notice at first it worked when I tried on a Linux machine (in Chrome but not Firefox) but after clearing my cache in Chrome it also stopped working. The Altair example also is not functional on a different Mac. I’ve never had any problems with this before--- even worked on a iPad.
So, I’m curious what might explain this loss of critical functionality. I realize this might not directly be an Altair issue but maybe related to Vega-lite or javascript, but I’m not knowledgeable about these at all.
This is due to a bug in Vega 5.12.1. If you render your chart with a different Vega version, it will work. See https://github.com/vega/vega/issues/2641 for more information.
Related
UPDTATE
Since Apple are $2 trillion company let's try and get them to fix this by submitting a bug report here: https://www.apple.com/feedback/safari.html
https://discussions.apple.com/thread/251753724?answerId=253364840022&page=1
In Chrome and Firefox there are no issues but here is the issue in safari:
its supposed to look like in chrome:
If I add fixed style="position: fixed" to the outer div then they position correct, but ther size is still the smaller one in safari.
I tried adding Body to the root of an object but that just made them disappear completely from Safari. Also this post mentions it:
Safari is not respecting scaling applied to a foreignObject
You can see very clearly hear that safari (new ie) does not respect the scaling
I have a scraping script written in Ruby which uses Selenium, Watir and ChromeDriver, all is working just fine with a Chrome browser window, but trying to run in headless mode just hits;
Selenium::WebDriver::Error::UnknownError: unknown error: Element <input id="desired_element" type="checkbox" name="desired_element" checked="checked"> is not clickable at point (660, 594). Other element would receive the click: <html lang="en">...</html>
I'm using Watir 6.8 and latest Chromedriver 2.33.
Any ideas whats n=behind the different behavior of the page when in headless vs non headless, and how I can deal with this?
The error message is telling you what the problem is when it says "Other element would receive the click:"
This means some other element on the screen is covering the checkbox you are trying to interact with. Likely this is caused by whatever the default browser size in headless mode being different than the default size of your browser when it is run non-headless, resulting in a different arrangement of elements
We can verify if this is the case by asking the size of the window in both headless and normal modes and seeing if the resulting values are the same.
size = browser.window.size
puts "The browser window is #{size.width} wide by #{size.height} high"
There are a few potential ways to solve this:
Specify or alter the browser 'window' size. for example
browser.window.resize_to 1024, 768
I prefer this, and normally have a command such as that to set the
browser size right after it is initialized. Set either to the
minimum supported size for your site, or the minimum recommended
size
Use another means to 'click' on the checkbox, such as sending a space at it
#browser.checkbox(name: "desired_element").send_keys " "
I do not prefer this as it doesn't really solve the source of the problem and you may experience other similar issues interacting with other elements on the site as your script progresses.
The reason for this kind of error is that web page doesn't load well enough to locate the element. As you have mentioned that the tests previously passed when you had headless true such issues might be because of .click() , please try replacing .click with .send_keys
.send_keys(selenium.webdriver.common.keys.Keys.SPACE)
When you use .send_keys() you might hit one more issue if it is failing to find elements, for solving this you will have to find the elements
elements = driver.find_element_by_tag_name("html")
elements.send_keys(Keys.SPACE)
Hope this helps you.
I am trying to port over a bit of code from wx2.8 to wxPheonix (3.0.3.dev78356 msw). I'm using code from the pyfa project (https://github.com/DarkFenX/Pyfa) which is currently being rewritten for python3. This code takes some concepts from PyCollapsiblePane and implements it better (there are some bugs with PCP). If you download and open pyfa, the collapsible panels are on the right side (resources, resistances, etc) if you want to get a feel for how it is supposed to work.
Anyway, I'm trying to port this over and I cannot seem to get it to work well. I know Pheonix introduces some changes to sizers and how things are resized. I am able to collapse the panel (and have the parent panel fit to the new size), and then open it again. But when I try to collapse it again nothing seems to happen.
Here's what is currently happening:
http://gyazo.com/68717f66c498d850ef60ee83e1c0ae4a
And here is how it's suppposed to work (wxPython 2.8 in the pyfa app)
http://gyazo.com/87cc0f61052dca0e81c387da0f84c0c4
This is the module that I'm working on (the script has a test case if run directly): http://pastebin.com/ghuVGXWN
Any ideas?
I had to remove self.SetMinSize(sz) from OnStateChange, works great now.
I have some YUI2 code (v2.8.1) that looks like this:
YAHOO.util.Dom.setStyle('foo', 'opacity', 0.5);
and:
var t = new YAHOO.util.Anim(this._splashSlide.shutter, {opacity: {from: 1.0, to: 0}}, 1, YAHOO.util.Easing.easeBoth);
It has been working fine for a number of years and it automatically decides whether it can use style.opacity or whether (for IE) it has to use the IE style.filter to achieve opacity. For a variety of reasons, it is not worth porting this code to YUI3.
Along comes IE 10, which (in standards mode) no longer has the style.filter property and only supports the standard style.opacity property. That's all good, but the YUI2 version I'm running against doesn't know about IE 10 and is apparently still using the style.filter property which no longer works.
So, my question is whether there is an update to YUI2 that is IE10 compatible and uses the opacity property for IE versions where that property exists?
If it was just a simple style setting, I could work around it, but I have a number of YUI animations and I can't find an easy way to work around those (nor do I want to spend the time doing so).
Has Yahoo fixed this for YUI2? Anyone aware of a work-around, particularly for the animation functions that call YD.setStyle() internally?
I guess I found an answer to my own question. YUI2 v2.9.0 changes their setStyle() function to use feature detection so they now properly use style.opacity on browsers that support it and only use IE's style.filter when style.opacity is not supported.
If ever one wanted a poster child for why browser detection is bad and feature detection is good, this is a perfect example. Because YUI2 originally used browser detection, it is now broken on IE10. If they had used feature detection in the first place, the older versions of YUI2 would work on IE10 without requiring an update.
Now, to see if I can get the site where my code runs to upgrade to YUI v2.9.0. If not, I'll have to code a messy workaround.
I have spent hours with this issue. I'm about ready to tear my project apart, line by line to get this figured out. But I was wondering if anyone else had this issue:
My project works great in Firefox. My customers use IE (classic - alot of people do...). My boss wants me to get this done yesterday.
I can't get IE 8 or 9 (with my document in IE 7 emulation mode) to run the following, and load the TabView. I get an error in the debugger console that telling me that it doesn't load it. I have all the required modules for tabview loaded via tags, so there is no dependence on an Internet connection - offline operation (again.. works great in Firefox).
YUI({bootstrap:false,insertBefore: 'yui3-style-overrides', filter: ''}).use('tabview','tabview-base','event-synthetic','event','event-custom','event-mouseenter','oop','yui','dom','dom-base','node','io','datasource','resize','anim','anim-easing','event-base-ie','dom-style-ie','node-focusmanager','node-event-simulate','plugin','classnamemanager','pluginhost','event-base','tabview-plugin','attribute','base','widget','widget-base-ie','arraylist','widget-parent','widget-child','event-simulate',function(Y) {
/* sand boxed code here */
});
Recently yui (3.2 or 3.3) factored out their ie fixes into separate files in the build. This caused a nightmare for me as well. You could test it with 3.1.1 if you want to isolate your variables.
What contributed more to my insanity was that I was stupid enough to use the YUI PHP Loader, which gets worse with every YUI release because YUI is getting so many dependencies even hacked up crap like the PHP Loader cannot account for all situations.
I worked around this by manually loading all the -ie- files using
<!--[if IE 7]><script type="text/javascript" src=myfile.js></script><![endif]-->
for a month or two before I was able to come up with a smarter but larger version of PHP Loader (Which, alas, I cannot share).
To see if this is your problem, use that if ie script above for every IE specific file in the build folder. Here is a list:
build/dom/dom-style-ie-debug.js
build/event/event-base-ie-debug.js
build/history/history-hash-ie-debug.js
build/scrollview/scrollview-base-ie-debug.js
build/widget/widget-base-ie-debug.js
If I were you, I'd manually load all of those except for maybe history, which you might not need - just so you can minimize your variables.
TBH, when I had this problem and troubleshot it, I loaded every yui JS file. It took a while, but the bug disappeared and I was hot on the trail of finding the -ie- files issue.