I was looking at this drag and drop demo for Jquery UI. The demo works fine at a normal zoom. But if you zoom out to say, 50%, things get wonky. http://www.elated.com/res/File/articles/development/javascript/jquery/drag-and-drop-with-jquery-your-essential-guide/card-game.html
Can anyone suggest a way to fix the demo?
As far as I know, browser zooms and javascript/jQuery don't play nice. A half a decade ago, zooming on the browser didn't zoom images (at least in IE), etc.
http://bugs.jqueryui.com/ticket/4140 Here's an issue suggesting that there's no way to fix zoom-related bugs that arise in jQuery. It's from two years ago, but it says:
Unfortunately it is impossible to my knowledge to reliably detect the page zoom and its value in any browser, so I have to close this ticket for now. If you find a way to detect it that doesn't cause significant overhead, please reopen.
I found that if you're in Google Docs and you use the browser zoom, an message will show alerting the user that different zoom levels are not supported. So I think the best choice for you, if you wanted to fix this, would be to do the same thing that Google is doing.
Related
I have an issue with drag and drop on Chrome (v69.0.3497.100). Specifically, some of the drag and drop events are getting fired when Windows scaling is other than 100% even though they shouldn't be firing.
Check out stackblitz example, and try to drag "blue" rectangle over itself (just drag, move a little bit downwards and drop). If Windows scaling is set to 100% (browser zoom is 100% as well) then one event is fired (dragEnter) as expected (check the console). But, if Windows scaling is set to 125% (but browser zoom is still 100%) then three events are fired (two dragEnter and one dragLeave), and I expected only one event to be fired since the element was dragged and dropped on itself (as it was the case with 100% scale level).
It could be that since this is Windows zoom (and not browser's zoom) the left ("lightred") rectangle is larger that it appears, and it goes below right rectangle, and events are propagated to it, although I couldn't prove that since all elements have correct size in the inspector.
This doesn't seem to be happening in latest Firefox, IE or Edge.
Does anyone know why is this happening and how to fix it?
The more I look at this problem, the more it seems the Chromium issue. Some days ago I posted a question, then I wanted to set up a bounty for it, and then I found your one, and I believe they are interrelated: Subpixel scroll issue, can't set scrollTop properly on Chrome 69.
There are some bug reports in Chromium issue tracker related to scale-rounding problem: link 1, link 2... I also created my own bug: link 3. There should be more information but it takes too much time to research. I think we may join efforts and draw more attention to the problem, and for example if it's Chromium responsibility, to help them with clarification and prioritisation.
I have the same problem with Version 76.0.3809.100 (64-Bit).
And I offset the image to compensate for the strange offset that I get in your stackbliz example too.
But with scaling 200% I need to multiply my calculated dragImage offset by 4 !!!
On 300% it's at 9
On 350% it's at 12.25
Do you see the pattern ???!
I'm afraid of my hack/fix for this problem. Not sure if it's just on windows, if it's just desktop. But for now I guess I will have to do window.devicePixelRatio^2 so I can continue my work.
There are instances where a website has drag-and-drop features that will not work inside the Google Chrome browser.
Fixing Drag-and-Drop
Enter the following into the Google Chrome Top search bar.
Chrome Flags: chrome://flags/
Type Touch into the search bar and set the following options to Enabled.
I am trying to implement a chat application, more precisely a scroll behavior for chat application. I think it's best described with a gif.
https://i.imgur.com/NnpMeOx.gif
As you can see, I want to support a few key features:
Scrolling is reversed so on page load, the messages start on the bottom along with the scrollbar
Chat is scrolled to the bottom when user types in a message. (this is easy, no need to pay attention to this part)
If new messages appears (pushed by websocket in real life) it shouldn't disrupt the existing scroll position, unless it's already at the bottom. Then it should scroll to reveal the message automatically.
So far I've implemented 2 solutions:
a) Display flex and flex-direction column-reverse on the scrollable element. This works beautifully out of a box, but only on chrome :( IE (and Edge) as well as firefox just ignores this totally. NOT A GOOD SOLUTION
b) I flipped the container with transform: scaleY(-1) then I reversed the messages and fliped every one of those with the same transform. The main obvious problem here is the scroll (mouse wheel and arrows) is reversed. I sort of fixed it, didn't manage smooth scroll (sucks) but yet again, Edge (and probably IE) just shows scrollbar as disabled. NOT A GOOD SOLUTION
I am really hoping to find somebody who can point me in the right direction because so far, my efforts while logically ok totally failed browser compatibility.
The code is on https://github.com/PeterKottas/react-bell-chat, it's react but tbh, that doesn't matter much as this seems more like a general web dev exercise.
P.S.: I can't use jQuery, hope that's fair. So either css or plain javascript. Like I've said, this doesn't have much to do with react
Well I got no replies and managed to fix it myself so I'll accept this in case it helps somebody in the future.
3rd and final solution:
I kept the direction of scrolling and didn't do any reversing at all. Instead I hooked into onScroll and wheel event, created a few callbacks and managed to mimic the behavior perfectly. You can find more details in the code on https://github.com/PeterKottas/react-bell-chat.
What is the best way to make a drag and drop builder in 2017? Yes, this question has been asked before but that was 5 years ago and I assume things have changed? HTML5, jQuery UI or is there another option now?
A more recent question Form Builder From Scratch - HTML 5 Drag and Drop, or JQuery UI Draggable, or What? was also left unanswered.
Any help would be great! I have started to play around with both (I have never used HTML5 or jQuery UI's Drag and Drop so it's hard for me to make a decision.) and jQuery UI does seem to be easier to use and understand but also seems quite buggy, well at least in codepen.
We just did a bit of research into Drag and Drop with ReactJs and honestly came out the other side a bit sad. So if you're looking for pure HTML 5 Drag and Drop this is a fantastic site to show you how screwed you are:
https://caniuse.com/#feat=dragndrop
So as of the time of writing this, if you went pure HTML5 DND you really wouldn't cover the mobile scenarios.
Now what isn't listed in this is all the edge cases to get the feature looking the same across browsers. Between Edge, Firefox and Chrome, one adds an Icon to show that you are dragging at item, one has a slight opacity on a copied element and one does something else. Either way, aligning these designs (depending on how annoying your design team is) can be easy (e.g. don't care as long as drag and drop works) to impossible (e.g. get rid of the icon while I'm dragging).
Now when it comes to JQuery, it's been around a while but that doesn't mean it doesn't have it's faults as well. Because it runs in the JS layer instead of the browser itself, depending on how much is going on in the system, it can feel a bit slow. Also I did notice it started dragging on annoying situations like when you're trying to swipe the page to scroll in Edge. That could have also been poor programming on our part.
I think in the end we just used React Dnd with the HTML5 backend. Seems to work pretty good and for those mobile scenarios we just have menu options which expose the same functionality in a different form. It ended up helping with accessibility as explaining all the actions for drag and drop via keyboard shortcuts was slightly annoying.
Not sure if that helps but if I recall (and it's been about 6 months) that's the run down.
I recommend using jqueryui with a small hack called touch punch that allows you to capture the events of mobile devices such as ontouch on the screen. I prefer jqueryui because it is more complete than HTML5 and relatively easy to use.
The link:
http://touchpunch.furf.com
Good luck and greetings
I have an element with a line graph in it that I want to be able to handle pinch zooms, so the user can zoom in or out on a certain part of the graph. This works great in every browser except IE11, where instead of zooming the element, it zooms the entire page.
Is there an obvious way to prevent this kind of functionality, so IE allows for pinch-zooming on specific elements? Or maybe there's some way to capture the pinch event, e.preventDefault(), and maybe zoom the graph manually?
I have asked a few other people to try to reproduce the issue, and it seems like it's not a problem on Windows 10... I'm on Windows 7. Could this really be platform dependent? But even if it is, maybe intercepting the events is a good approach? Any suggestions would be greatly appreciated.
Here's an example of a chart where I am having this problem:
http://demos.wijmo.com/5/Angular/FlexChartZoom/FlexChartZoom/
According to the official documentation, programmatic control of touch and gesture recognition requires Windows 8 or later.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.