I have a tabulator table with selectable:true, in its definition. However there is a problem: Holding the shift button down and dragging does NOT select multiple rows. I tried with: selectableRangeMode:"click" and/or selectableRollingSelection:true, without any effect. Note that I style the even/odd rows via CSS: .tabulator .tabulator-tableHolder .tabulator-table .tabulator-row.tabulator-row-odd{... if that has any effect. Please help. Thanks.
Not working for me in Firefox either. I am using Firefox Quantum v64.0.2 (64-bit) on Linux.
There also seems to be a GitHub Issue already for this: https://github.com/olifolkerd/tabulator/issues/1803
The developer is very responsive and hopes to have a fix in a future build. He alludes to it being a Firefox issue for which someone filed a Firefox bug report and he also suggests click functionality to be the most consistent experience.
Related
I am using handsontable 0.18.0 version in my application. In the handsontable we are loading collection of data in tree view form, We can expands their childs. If we expand the childs and update any particular cell, we are facing performance issue (it takes almost 20-30 secs) in IE browser, but in chrome it is 3-6 seconds. Without expanding nodes it will take around 3-5 Secs., only.
Can anyone suggest how to overcome this issue?
Thanks in advance.
One of the issues with IE is the way the virtual rendering occurs. The reason chrome and other browsers are so fast is that Handson uses this type of rendering to only show the rows in your viewport. It is a known issue which is why if you look at the compatibility table, it says IE is known to have "Limited ability to handle large amounts of data".
The solution would be to upgrade your browser or try to implement a type of virtual rendering yourself. The latter can be daunting but the only solution, unfortunately.
On this website (tested in close-to-latest
Opera, Firefox and Google Chromium on Mageia Linux 3 Cauldron and on Firefox on my Arch Linux VM), the expanders/[+] signs of the navigation menu on the left get shifted a little
upwards and downwards when the sub-menu is expanded/collapsed. That's not the case if the expander in question the last one in the sub-tree (for example, under "Humour" →
"Recommendations").
Why and how can it be avoided? Is it because of the different character in the text? I tried setting it to monospace - it did not help.
It works fine here, but the CSS and generated
DOM are different.
(Note: this is my permanent site while this is the
temporary/testing one. They look mostly the same now, but do not use exactly the same markup, CSS and JS.)
The problem is that I'm trying to make jqTree look more like what I had in the old
jQuery Treeview, and it won't cooperate. I spent an entire day on it yesterday,
and while I fixed many problems, I still have this one.
I tried using Firefox's Firebug, Opera's Dragonfly, and the equivalent tool in Google
Chromium has, but I lack the necessary skills to understand what goes wrong.
It appears that the jQuery Treeview authors tried to optimise performance by using a single image with a different background-position which makes it hard to debug, and I didn't get rid of it yet.
Any pinpoint to the problem, and/or a fix will be appreciated.
Following is the behaviour of DOJO 1.8 auto suggest in IE 8
http://dojotoolkit.org/reference-guide/1.8/dijit/form/FilteringSelect.html
It shows special characters between the text in IE8.Check the above link to see the exact behaviour.
I guess the issue is with the latest DOJO relaese ,please help me out.
The FilteringSelect uses a unicode annotation character to highlight the matching part of the suggestions. I see the same thing here, so I guess IE has a problem rendering them and it slipped past the dojo tests.
No idea how to fix it, but as a temporary measure, you can set the FilteringSelect's "highlightMatch" to "none".
Edit: It seems to be a known bug related to the build tool/shrinksafe: http://bugs.dojotoolkit.org/ticket/15969
I seem to face a problem with displaying and selecting the dropdown while using the flexslider in my mobile website.
Here, similar problem was listed. But the solution didn't work for me. I did use useCSS:false, somehow that didn't work for me too.
I use Android GingerBread.
I can submit buttons, enter text, use checkboxes but just not the dropdown. Any advice is welcome.
==Edited==
I found a somewhat similar reported issue here: https://github.com/woothemes/FlexSlider/issues/82
Even if it is a webkit related issue, can anyone suggest any solution for this?
Sometimes the dropdown from other slide is displayed, despite having backface-visibility:hidden.
Somehow I must've missed the proper documentation for something as simple as this. Searching via Google does not exactly yield useful results either.
So, here's what I want to do: Draw a rectangle (div), make it draggable and drop it somewhere else, with a proper validation that the drop point is an actually valid one.
How would I go about doing that with the tools provided by the Visual Studio 11 Beta?
All I've found so far is the onDragging-Event which is not really helpful due to the scarcity of information provided.
Code sample would be great, I could also live with a link to some blog or such.
Edit: Drag and drop through touchscreen input, that is, not through the "normal" mouse interaction.
Just got a reply from a Microsoft employee: It's a bug:
http://social.msdn.microsoft.com/Forums/en-US/winappswithhtml5/thread/88cfb689-2e38-417c-a2be-9682f1a23ae4/
So, until that bug is fixed, it seems you really have to roll your own.
The following link a walkthrough of HTML5 drag/drop in IE10 from the IE blog. IE10 is the engine for Windows Web Apps so this will work in your Windows 8 app.
http://blogs.msdn.com/b/ie/archive/2011/07/27/html5-drag-and-drop-in-ie10-ppb2.aspx
Up until and including the beta (CP) we were able to use the dragstart, drag, dragend events even for touch input in Metro. In the newer builds this has stopped working (events don't fire anymore) and it looks like we'll have to switch to MSPointerMove et al. for handling touch-dragging.
From a few samples I created it seems that standalone IE has never supported dragstart, drag and dragend for touch - in other words touch drag works in my sample inside beta Metro, but same file doesn't work inside normal IE there.
Re the answer from Microsoft employee mentioned below, I believe that bug is unrelated to the issue of touch-dragging.