I have a problem where moving the cursor and clicking in text fields causes the page to show a wait cursor and also makes the page very unresponsive.
See this video for an example of it happening.
It only happens in IE7.
I've tried checking where I think it might be sending off ajax requests (thought this could be changing the cursor).
I've checked where I think multiple events may be firing simultaneously and tried commenting it out.
Has anyone seen anything similar happen and can point me in the right direction?
What is IE7's criteria for displaying the wait cursor?
Eventually I narrowed down the issue. After eliminating code bit by bit I deduced the problem isn't caused by JavaScript at all, it's a css issue.
The exact line of css is
overflow-y: auto
I don't know exactly the circumstances to reproduce it. But for a bit of info that might help others... The container the css is applied to is positioned absolutely. It has a fixed size (which also seems to be changed in JavaScript) and width. It's parent container is a div with display:block;.
Curiously if you scroll to the bottom of the container and back up it seems to fix the flickering bug.
Related
I know that this is not a 'good question' to pose—but I'm desperate by now and need to find some inspiration.
I have a questionnaire page/web-app that uses CSS transitions to slide to the next page of questions/options.
It is well-tested and the transitions in question aren't complex.
But the transition to one special page went out of control recently. And although I consider myself well versed in CSS and JavaScript I'm totally lost with this problem.
The construct in question works like this:
I have a 'window' that is positioned absolutely and has its overflow hidden.
Inside that is a page container positioned relative to no left or top values or transforms given.
The pages inside this container are positioned absolutely according to their status classes positioned on the left: 0 (active), left 100% (not yet shown), and left: -100% (already done)
What happens now is that when I switch classes to show a certain page, the page container 'jumps to the left'. In Chrome nearly -100% in Firefox about -70% same in Safari.
Those values are my guess because when I open the dev-tools, nothing is to be found in the styles, in the computed values anywhere.
When I move back to the previous page the container jumps back to its original position, and if I move again to the critical page it stays.
I do no positioning whatsoever with JavaScript anywhere, I only switch classes on HTML elements.
After hours of experimenting back and forth, I found out that the problem is in some way JavaScript-related anyhow.
Using the exact same CSS and HTML with a slightly older version of JavaScript does not show the strange behavior. The changes in the Script are mostly ES2020-module related, and the new version does nothing even remotely related to DOM manipulation different from the older working version.
When not using transitions, the shift of the container does not occur.
Has anyone come across something similar?
Does anyone know of other tools to deeper analyze the current layout state of a page more than the respective developer tools of the browsers?
Any other ideas?
Today I found a solution and at least some kind of explanation, but I still have to investigate some more to truly understand the why and how. I'll post an update if I find a better explanation.
The problem has to do with a text field and focus.
The page in question has a text (search) as its main component.
[I am aware and always was that browsers try to move focused elements into view, regardless of what the author's CSS says.
Therefore, when I decided to give focus to the text field which it does not have on its own, as every page movement required a button to be clicked, I did so on transitionend. This has never changed.
When the issue first occurred, one of the things I tried first was to disable that (auto) focus behavior. It did not solve the problem.
I cannot say what made that change in behavior happen. I change the construction of the page to include a grid some time before the issue occurred. That in itself was not the reason, however (it worked for quite some time with that system, and removing it did not sole the behavior).]
What solved the issue was to initially fully disable the text field and only enable it on transitionend (then focusing it).
The reason browsers moved the page to different positions likely has to do with this situation, as the text fields width is ch based.
The important takeaway (for now) for me is, that there is no hint to be found in the developer tools when the browsers moves - elements in the (in my case unsuccessful) attempt to keep inputs in the viewport.
I think that this should be changed/fixed.
I will as soon as I have the time try to better understand the things that made the problem occur, If someone has information or experience with similar situations pleas add useful hints and background info.
Alright so I'm really stumped by this one. How can I lock the page's scroll position to a specific value? I can't use overflow: hidden; on the body, because that prevents scroll events from firing entirely. I can't use scrollTo(0,0) every time the scroll event fires, because that causes a terrible stuttering effect.
What can I do? How can I lock the scroll at a specific spot? I've been scouring the internet and I've found nothing. A friend and I have been working on this for like an hour and can't think of anything at all. Any help is appreciated!
EDIT: I'd like to achieve an effect identical to what is shown on this page: https://www.apple.com/ie/macbook-pro-16/
I am working on a website and added an animation of clouds flowing using adobe edge animation.
http://avuedesigns.com/iaq/
I have created a thread over at the adobe community (http://forums.adobe.com/thread/1128782) and it seems that my code to make it responsive, and the overflow are correctly setup.
So basically I have no idea why WordPress is either breaking it. Or why my little bit of code thinks the website is wider than it really is. Maybe fresh eyes can see something I am not.
correct your container has an overflow attribute most likely set to scroll within your css file.
set this to;
overflow: hidden;
Well, wordpress is just a cms engine that spits out html - it is hardly to blame. I do see that the width keeps changing and the horiz scroll bar appears and disappears which is definitely not optimal.
I think the starting place is with the main container div....do you have overflow:hidden set? This should allow your clouds to appear outside of the visible pane without forcing the div to change width.
I've got a page with ajax links between pages, and I'm having some problems with the transition. I set up a demo page on jsfiddle to demonstrate.
http://jsfiddle.net/UVr4A/
The problem is, when the content changes height, the div will end up in the wrong position and cause a non-smooth transition. I tried a couple things to try and fix this. My current solution is to remove the animate property from the div and then move it, but this doesn't always work. In my code I commented the delay to demonstrate the issue. Even with a 50ms delay it doesn't ways work properly (I think it's due to browser lag since it barely ever happens on this jsfiddle), so I'm looking for more elegant solution that doesn't cause the transition to take any longer.
I'm using css3 transitions rather than jquery because they tend to be much smoother.
I think the issue was the css transition. Check this out:
http://jsfiddle.net/UVr4A/2/
Well, it turns out the problem had nothing to do with what I thought it was.
Part of it was that I over-simplified my question and ended up removing the problem.
On my long page there are images that end up loading mid-transition, which is what was causing the jumping. I fixed this with an onload events and a timeout.
A simple mobile landing page located here: http://happyappe.com/mms_Mobi
Not sure why, but when the About Us and Products pages are expanded the animation jumps past a certain point. Could anyone give me an idea as to why? Not all too familiar working with javascript.
Appreciate it.
I believe this is due to a known bug and the current workaround is to specify a solid width for the animated element. I tried setting one of your collapsible divs to 280px and the animation smoothed immediately.
Edit: Found what appears to be the bug ticket related to this issue
http://bugs.jquery.com/ticket/8370
The ticket has been closed and can't be fixed, the comment at the end reads:
Unfortunately there's not really anything that we can do on our end to divine the right height. Setting the width (as previously mentioned) will achieve the correct result - I recommend doing that in your scripts.