When dynamically adding custom css classes to a dc.selectMenu IE11 kicks them out when filters are applied. For now I push them in again using a renderlet. This causes "glitches"/moves content around due to added padding or widths/heights.
You can reproduce the issue by selecting an option from the select box in my block.
Is this a bug? Does anyone know a cleaner workaround not causing these glitches to appear?
We found that IE11 actually crashes on Win8 if you try to update a selectMenu! So we only render, don't attempt to redraw selectMenu on that browser.
So that's why you need to re-apply it.
In experimenting with this, I found that it was enough simply to move
.on('renderlet', ...
to the selectMenu, where it arguably belongs (because it's modifying that widget). I think this works because the select menu doesn't use any transitions, and there is no delay.
More generally, though, in any modern version of dc.js, you should really use the pretransition event, which fires before any transitions. In sum:
selectMenu.on('pretransition', function(chart){
selectMenu.select('select').classed('uk-select', true);
});
Although it's a really cool word, renderlet is rarely the right event to listen to. You'll see it in a lot of examples because it goes way back to early releases of dc.js, but it occurs after all transitions have finished.
If you use pretransition you'll have a chance to change things before the browser even refreshes at all.
Related
I am using Monaco Editor 0.22.3 in combination with StencilJS and TailwindCSS. Everything works great, except for an annoying visual glitch in the intellisense dropdown as depicted here:
As you can see, the last suggested item is partially obscured.
I suspect it might have something to do with some style coming from TailwindCSS, but I'm pretty much at my wits end here. I tried to use the F12 element inspector to see if I can find some hints, but that is proving to be close to impossible since the intellisense dropdown disappears as soon as it loses focus.
Any hints would be much appreciated!
UPDATE 1
Here's a screenshot with a bigger editor to demonstrate that the dropdown itself does not appear to be clipped:
UPDATE 2
Here's an animated gif showing the issue when trying to debug the HTML elements using the browser developer tools:
As you can see, the dropdown disappears as soon as I click anywhere else.
The issue comes from a fairly common css class being used: .tree. Libraries such as tailwindcss add padding-bottom to it for example. To undo some of its additions for the monaco editor we added the following to our css file:
.monaco-editor .suggest-widget div.tree {
white-space: unset;
padding-bottom: 0;
}
And to get get to that solution for other libraries and styling artefacts:
It should have been quite easy but the suggestion dialog has a tendency to hide when we try to observe it. so a UI guy and I spent a while going through the playbook to try to debug it. The only successful way to inspect it was to abuse the JS debugger by running (which was a hint from a stack overflow post that I'm struggling to find to give credit), and just cause the JS engine to pause:
Run:
setTimeout(5000);
This gives us 5 seconds to get the suggestion window to show (or set to a relative amount of time to the problem). After which, you could mostly inspect it as normal with a quick shortcut:
ctrl+shift+c that brings up the debuggers element selector.
Here we are, the suggestion was from the following post:
How can I inspect disappearing element in a browser?
break on subtree probably would have worked, but we became a bit impatient stepping through the changes. ctrl+ / didn't seem to help in this case, which left the odd setTimout to save the day.
The drop down is clipped at the editor's boundaries. I actually wonder how you can see the last empty part outside of the editor.
For inspection: use your browser's dev tools to see how the containers overlap. This will avoid that the editor hides the drop down.
Update
After your update I think now that somehow the styles are messed up. You will have to figure out a way to show the popup and still navigate the DOM tree in the developer tools. Try to locate the parent and see if that popup is only hidden (it still shows up then in the tree) or if it is dynamically created or is a portal, which lives in a completely different part of the tree.
If that cannot be done then try to disable all CSS you have and see if that solves the issue. If so enable the CSS piece by piece to find the culprit.
I've read somewhere, (unfortunately I can't find my source again) that if a user has loaded an HTML page with a running CSS3 animation (infinite parameter) and he decides to leave it, the browser (computer) still needlessly plays the animation and so, CPU (or Acceleration hardware?) is still working for the animation although the user left the page.
So if someone could answer me, I will be pleased.
Is this fact true?
And if it's true:
Are the transitions also concerned with this issue ?
Is pausing animation (and transition if concerned) enough to avoid this problem? (I was thinking to force the pausing with an onbeforeunload event) Or should I have to do another thing ? Notice that I don't want to use "hover" to start the animations/transitions.
PS: I'm still new in CSS, javascript and know no other language. And sorry but my knowledge of English language is far from top...
If the user leaves the page completely (e.g. navigates to a whole new page or closes that tab) then the animations shouldn't keep running. If they somehow do keep being updated, it's because of a browser bug and you shouldn't worry about it anyway.
However, CSS3 animations for hidden elements (display: none;, for instance) still get evaluated, since they are keyframe-based, and there might be a keyframe sometime in the future that would cause the element to become visible again.
Imagine wanting to animate a box by first hiding it, then showing it again and making it flash. If CSS transitions would suddenly become disabled when the box is hidden, the animation would stop and the box would never appear again. And that's not what you want.
Note: profiling your web page can be done e.g. in Chrome using the Developer Tools (F12 -> Profiles). I haven't used it to profile CSS3 animations though, so I'm not sure if it can be done. You can however just take a look at Chrome's very own task manager (Shift-ESC) and see whether your website is using up a considerable amount of CPU. If that's true, then it's a sign that there might be too many animations on that page.
I'm noticing a strange bug in Chromium/Chrome, when after some edits one or more gallery placeholders (the camera and picture in WP3.5) disappear. In one case, I have one placeholder that displays, and the one above doesn't, inspector shows that one doesn't have the img.wpGallery style applied to it, though they both should be working.
Working:
<img class="wpGallery mceItem" title="gallery ids="77,76"" alt="" src="http://localhost/wordpress/wp-includes/js/tinymce/plugins/wpgallery/img/t.gif" data-mce-src="http://localhost/wordpress/wp-includes/js/tinymce/plugins/wpgallery/img/t.gif">
Another, not working:
<img class="wpGallery mceItem" title="gallery ids="32,22"" alt="" src="http://localhost/wordpress/wp-includes/js/tinymce/plugins/wpgallery/img/t.gif" data-mce-src="http://localhost/wordpress/wp-includes/js/tinymce/plugins/wpgallery/img/t.gif">
These were right next to each other, yet inspector verifies that the img.wpGallery rule does not apply to one of them, therefore it disappears.
This odd bug seems to be caused by an odd state of the editor - saving or reloading shows it correctly again, until you start clicking around and editing. It almost seems like a graphics/webkit bug. It seems to be random when it happens, but adding multiple galleries, typing directly after, before, clicking out of the editor, in the editor, repeating a few times, usually can make one or more galleries disappear...
Is this a known bug in Wordpress, TinyMCE, or Webkit? Has anyone found a solution?
I'm seeing this on two WP installs, on two different systems, and even on the default theme.
Seems to be related to a chrome bug. It will be fixed in Wordpress 3.6.
(see: http://core.trac.wordpress.org/ticket/24177)
It is suggested to rename the css-classes from wpGallery to wp-gallery.
Surprised to see someone with the same obscure problem as me.
What I did to work around this was move my CSS to the image's style attribute. Of course I had complete control over the elements being rendered... not sure if it'll help in your case.
Looks like a simple workaround is to go through the tinymce.activeEditor.contentDocument.getElementsByTagName('img') elements and set element.className = element.className. (This can be added in many handlers like onClick, onChange, etc. to prevent the weird state when the class doesn't apply itself.)
This seems to be a good workaround, but I would like to know how/why TinyMCE with Webkit gets in this odd state though.
I'm trying to implement a custom image cursor in CSS, e.g.
cursor:url(/img/custom.png), pointer;
this works great, except when the mouse moves over a flash element (e.g. embedded youtube video). Then it reverts back to the standard mouse cursor. Is there a way to override this?
The best "solution" would probably be to include the custom cursor in the flash as well.
Not really a perfect solution, but this site suggests putting an empty div that loads the movie in when you click it (also helps initial page load time).
I'm not sure if it works, but this site says it has a way to have a javascript command activate. Might be more than you want, but I know the solution listed gets rid of flash objects seemingly infinite z-index (thus I know it can override part of it).
I've noticed whilst optimising animations for use on iPad using hardware acceleration, I seem to be coming across an issue that I haven't fully been able to resolve. If you are applying webkit transforms such as translate, although the animation runs great, if in the middle of an animation occuring the user scrolls the page, when they release it causes the animation to stutter whereby it reverts to its original position and attempts to continue its animation to it's end point.
I've been looking everywhere for resolve on this issue, having seen it occur on the iPad store as well! If you have an iPad at hand and you navigate to, for example: http://webkit.org/demos/transitions-and-transforms/ , if you select an item then before the button animation has completed drag the page(scroll) then release it, you will see the animation flicker back to its original position and then repeat until its complete.
The only way I've been able to work around this is when a touchmove event occurs, I tell the animation to just stay where at its original location, which stops it from trying to repeat the transition on release, as even attempts to just tell it where to go again cause it to revert regardless (seeing as how css transitions seem not technically able to be stopped).
Has anyone found any workarounds to this issue, I'm pretty sure this is a bug on iPad as opposed to a problem with the animation (this does not involve issues regarding preserve-3d and what have you), or if I should be reporting this as an issue.
Thanks!
Not sure if I'm reading between the lines, but I suspect you might see better results if you use touchend versus touchmove or touchstart.