Ok so this bug is very weird
here is my code, you can actually see this bug happening using fiddler
http://jsfiddle.net/LLMUX/13/
the code works fine as long as you don't go to a different tab. the code is a rotator. if you hover the links it will show the block the hover is assigned, then once you hover off it will resume the main rotation
produce the bug
- have the fiddler page open, you could copy the code into a file and try it, same thing happens
- with the fiddler page you can hover or whatever you want or do nothing
- open another tab, do whatever for a few seconds 5-10 should do
- go back to the fiddler page
- chances are you will see 2 blocks showing then eventually 1 goes away
this only happens if you are coming back from a different tab, if you stay on the page this will NEVER happen. I tried is safari, it did not happen I tried it on IE9 it did not happen! I tried this on FF 7 and 8, both with this problem.
If anyone have any idea on why this happens it would be greatly appreciated
Edit - might not happen 100% of the time
I bet your problem is the same as this: Jquery setInterval too fast when coming from another tab
Browsers try to minimize the performance hit of web pages being active when the user doesn't interact with them. One such optimization is setTimeout/setInterval "clamping": Firefox 5+ doesn't fire timeouts faster than once in 1s.
I see that your code only uses a 1300ms interval, but I guess jQuery's animation deals with being in background in a different way than your setInterval-based code does, but I'm not up to debugging this to know the exact reason it works like that.
See also Background Tab Animation and jQuery
(edit) and if I'm right, the way I'd try fixing it is to stop using setInterval to drive animation and instead to always use the jQuery's 'finished' callbacks to schedule the next slide via setTimeout: fadeIn --> wait 1s --> fade out --> fade in.
Related
I am no programmar nor tech savvy person myself.
I just wanna know if it's possible to achieve this goal:
The default behavior of the browser(e.g. chrome) is it sends one page up or page down depending on where I click(above or below scroll thumb).
But when clicking somewhere on the scroll track, I wish it navigates right through the target position in the web page.
for better understanding, here's the screenshot of cnn.com main page for reference:
(In first screnshot, I highlighted where I will click.
Second screenshot is the default behavior of the browser as a result.
Third screenshot is what I want realize for my own convenience. it's useful when navigating through long articles.)
I think it is almost impossible to do this on my part because maybe it's hardcoded in browser's engine level or something, but I wanted to make sure it really is.
or any workaround like making autohotkey script or something?
thank you so much!
There seems to exist a trick with Shift, but it doesn't work in browsers.
However, you are manipulating a browser, and browsers have a built-in scripting language — JavaScript. Here's the setup you need to do:
Go to the place on the page you want to scroll to.
Open the developer console (Ctrl+Shift+I and then click on the "Console" tab). This shouldn't interfere with the scroll position.
Type window.scrollY and press Enter.
After that, the console will output the amount of vertical scrolling. In the following AutoHotkey code I'll use 12345 as an example; replace it with the value you have. Note that it also scrolls to the left margin.
Send {F6}javascript:window.scrollTo(0,12345)`%3Bvoid`%200{Enter}
It appears that, due to a bug, this doesn't work in Firefox.
I know your problem, I think chrome must have this config, you can type in the address bar "chrome://chrome-urls" for searching
I have a grid in ExtJS 6.0.2 that can be set to auto-refresh (it reloads once every ~10 seconds), but when it does, I want it to stay where it is instead of scrolling to the top each time. We have successfully used preserveScrollOnRefresh to do this with other grids, but for one particular grid, it's not working. In order to try to get it working, I decided to try calling getScrollY() before reloading the store and setScrollY() after, but that didn't work either. When I stepped through with the debugger, for some reason, getScrollY() returned 0 even when I had the grid scrolled all the way to the bottom.
Is there anything else that I can try?
it sounds like this is working for other grids in your app, so without seeing any code I'd suggest that something with that store/grid ecosystem is not configured the same as other grids in your app.
perhaps post a fiddle (fiddle.sencha.com) with an example, that may also help you find your answer if the fiddle works.
As you can see, the actual length of the request and its subsequent response is very quick. You cant see it in this view, but the blue bar represents a transaction that took 9 milliseconds.
The two lines, red and blue (which completed nearly instantaneously and are thus very close to each other), pictured far to the right of that, show up around 51ms.
So, what is happening here? is this actually time being spent? or is it just how the browser records it?
Your request took 9 milliseconds to complete
After that your browser received some data, it converted this into an html object(DOM) and displays this on your screen(DOMLoaded)
The action of converting and displaying took your browser 42 milliseconds, which is the gap between response and domLoaded.
edit:
I didn't manage to find the exact things the browser does but when i look into the dom of an empty page (which takes 100ms on my browser btw) i can find things like local storage, screen resolution, geo location and history.
Besides that i can imagine that cookie and add-ins can also take up some time if they are hooked. My ghostery for example is ment to block trackers so i assume he does so before the page is fully loaded.
I wish i could have given you a list of things the browser does in that window but alas. Maybe someone else can provide an actual list.
I'm trying to use dragAndDrop in the Firefox selenium IDE but it's not working.
I'm a big fan of selenium but this problem has been driving me crazy for the last day.
I have a dragAndDrop test:
dragAndDrop
//div[contains(text(),"Lori F.")]/../../
0,160
but it doesn't do the drag and drop. I have seen it work a couple of times but not sure why / why not now. Seems to sometimes work and sometimes not.
The selector itself DOES works when I click on the IDE [find] button. It highlights the DIV I am trying to move. So this is not the 'usual' problem I have in selenium of not actually being able to select the object with the right xpath.
The HTML it is going against is:
<div class="fc-event-inner fc-event-skin" style="background-color: yellow;">
<div class="fc-event-head fc-event-skin"></div>
<div class="">
<div class="fc-event-title">
Lori F., Marshal H., Chris W., Kenna T.
</div>
</div>
<div class="fc-event-bg"></div>
</div>
When that actual step tries to run, the browser does actually 'flash' the object, indicating that it's able to select it via the path OK, but the drag and drop doesn't happen.
I have tried dragAndDropToObject, using a div, but this didn't work because the DIV itself needs an x,y coordinate in order to 'land' on the right spot.
Two problems I have found [this may help other people] - and eliminated - were that 1) zooming in/out on the screen messed up the x,y coordinate for the drop, so I stopped doing that and 2) Using the element inspector in firefox seemed to also stop it working. So I believe I've eliminated both of these as potential causes.
Being able to test drag-and-drop is pretty important as many applications are now taking various ajax routes with this kinda stuff so being able to test it is key!
Sometimes drag and drop does not work properly (I don't know why).
So you may use workaround to simulate the same actions but in another way:
1) mouseDownAt(locator, coordString) - here you press down left mouse button and hold it
2) sometimes it is useful to wait for reaction (e.g. wait for tooltip appears or something else). At least put small pause to be sure that mouse "captured" the object and can drag it (tests could run very fast and browser may not react properly)
3) mouseMoveAt(locator, coordString) - drag where you need
4) mouseUpAt(locator, coordString) - release your mouse button finishing drag and drop
Also, you may add in the beginning of these steps setMouseSpeed(pixels) to make the mouse move slowly (to be sure it can drag) and in the end setMouseSpeed back to its default value (default is 10 meaning that mouse step is 10 pexels. Setting speed 3-5 pixels will make the mouse move slower).
Try to experiment with: mouse speed by setting different values and wait (after mouseDownAt) by changing locators (tooltip, shadow if there is any) or just put a pause of 1-2 seconds.
My jScrollPane (division) works well in IE and Chrome. It may be of some significance that I am also running JQuery MouseScroll and hoverintent. Again, these functions work fine in IE and Chrome.
The division is displayed properly in Firefox, as is the vertical scrollbar. There's about 50 lines to scroll down through.
In Firefox, the dragger fills the entire length of the vertical bar and doesn't move. The dragger and the arrows do respond to mouseover, but the functions don't work.
Perhaps the scrolling action is functional, just that there is no space to scroll, because the dragger fills the entire region. I am unsure whether my jScrollPane works or doesn't in Opera or Safari.
I checked Google and found little directly associated advice, just to:
"Ensure that the division has a height specified (it does) and to try refreshing (no luck) in case the content (only text) needs to pre-load."
I wonder whether anyone can suggest any checks for me to make from their previous experience before I post any code to wade through.
This is only the second question tagged with jScrollPane & Firefox, so perhaps no-one will be familiar with this 'bug'. In which case I will create and post some reduced code which generates this bug in Firefox but not IE or Chrome.
Update: I created a 'test' scrollbar webpage to see if the bug would be replicated, and that works fine - so no need to post that for error-checking.
The problem must lie somewhere within my code on the site I'm working on.
So far I have identified that all the JavaScripts work and my custom jScrollPane CSS is fine. So it's just a process of elimination through each of the stylesheets now. I have a feeling the source of the bug may be in my custom reset CSS.
I'm confident I'll fix the bug, and will let you folks know either way.
The bug was in the CSS reset as suspected. Specifically, with the rule for column-count.
I had defined them (moz-/wekbit-/column-count) as '1' instead of the defining as 'auto' / not defining it at all.
This was from when I was experimenting with (CSS3) multi-column text. Presumably jScrollPane requires multiple columns. Not enough support yet for multi-column text to be worth implementing yet IMO.