I have to debug a menu that "Wiggles" when the user mouses over each element in it. This only happens in Internet Explorer. In other browsers if I'm looking at markup it will update as events are triggered or styles applied and you can see that in the style trace. IE does not do this, if it can I'm unaware. Is there any way to see updates to the styles/markup in explore, live in the markup/style view, while interacting with the page?
This sounds very much like an old white-space bug. Is the menu formed from the Unordered List? If so, do you have carriage returned between each list item (ie each <li></li> is on a separate line)?
If so, try removing all the whitespace (so all list items are on a single line).
So my problem was that the menu items would "wiggle" when the user would mouse over each item. The problem was that this only happened in Internet Explorer. Where other browsers will let you watch a "live" view of the markup and styles, IE only allows you to refresh that view by clicking on a button above the view or using F5. That complicates things because if your moused over the browser F5 will reload the page. While if you mouse out and refresh the menu item has lost it's change by the time you click the refresh button.
My solution was to isolate the functions called by the mouseover and mouseout events, which were 7 character dynamically named garbage. Once I had what they were being called I could call them and trigger the mouse over and out actions on my own. Then I was able to refresh the markup view and see the styles, applied styles, that were changing.
Turned out that the on mouse-over event added a style that stripped the padding on the top and bottom of the element. In every other browser the box model is rendered so that this didn't matter. In IE it meant that everything would "wiggle" as you moved though the menu.
Gotta love legacy code... and IE.
Related
OK, I'm trying to reset the activeElement from the middle of the page so that the tab key would start from the top like, the same way as the page is just refreshed.
For that purpose (tested in FF and Chrome) I'm trying to use document.activeElement.blur() (from the browser console). As result, the selection of the <a href></a> gets visually removed (nice).
Also,running
document.activeElement after running document.activeElement.blur()
from console shows
<body class="ng-tns-0-0">
which looks good (the activeElement is body now?)
However, if I close the console and hit the Tab key, the focus appears on the next to the previous a href - Not to the link that is focused on page load + Tab key.
Why and how to fix that behavior?
The question appeared from the accessibility point of view, as the significant part of the page gets rendered with another content. The tab key needed to start over, like for a new page.
In fact, you shouldn't use blur() ever, and this method shouldn't even exist.
After having called blur(), you have no control of where the focus goes. It may go in menu bar, toolbars, or even go totally outside of the browser and/or become completely unrecoverable without a mouse.
The behavior you observe with firefox and chrome isn't standard, isn't specified anywhere, may depend on OS and/or browser settings, and you don't have control at all on it
The safest solution if you want to go back to the first element of the page is probably to focus that first element, rather than calling blur() and hope for the best.
In order for any application or website to be keyboard accessible, the focus must always be under control, i.e. you must always know exactly where it is. As the method blur() doesn't specify where the focus goes next, you lose control of the focus when using it; so you should never use it. As far as I know, it has probably no legitimate use.
This is a tricky one to describe but here goes.
A select control with a size > 1 is positioned in the browser down the bottom of the screen such that there is a scrollbar present in the body and only the first item in the select control is visible (the other items are there but you need to scroll the page down to see them). There is an onclick event in the select box or any parent above it but such does not fire when the select is clicked the first time. What happens is that chrome automagically scrolls the page to show all the items in the select, but apparently forgets to pass the click event to the handler.
This behavior only seems to occur in chrome. (works fine in FF and IE)
Chrome developers are notoriously slow to fix bugs and especially given the obscure nature in this case, I suspect it will never be fixed.
Using setTimeout in the onfocus event (in addition to the onclick event) solves the problem as the onfocus doesnt seem to be inhibited. However I would like to find a less hacky solution if there is one.
Ideas?
I'm currently toying around with some autocomplete form fields, and am finding it very hard to inspect the generated drop down items. As soon as I click on the "inspect element" button or try to right click on the dropdowns, the original autocomplete input runs an onclick event (or something that triggers on a focus change) and hides, deletes or otherwise modifies the element I was trying to inspect.
Is there a way to work with the debugger so that the mouseclicks and other commands I give to it don't get intercepted by the script I'm trying to debug?
I currently have this kind of problem on both Firebug and on Chrome's inspector. The only solution I can think right now would be setting some smart breakpoints inside the appropriate event handlers but that is hard to do if I don't know what event handlers to look for or where they are hidden in the original code...
You could set a breakpoint and inspect after it is triggered, I have noticed that freezes the DOM.
You need to use breakpoints. As far as tracking down what's happening where, Chrome's "Call Stack" window can be very helpful.
Cheers
In Firebug you have a Break on next item in Script panel. Since Firebug 1.10, there's a keyboard shortcut for this: Ctrl+Alt+B on Windows (it works even if focus is in the page, not in Firebug).
You'll probably need to have Script panel focused in Firebug since this is a shared shortcut for Break on... which differs in each panel.
It generally freezes the DOM although it's not 100% reliable.
It's also not ideal because it will stop at any JavaScript execution, and will not be helpful if there is some aggressive polling in the background, or global capturing of keyboard events. Anyway it's still better than nothing.
Chrome pauses Javascript execution on F8; it took a bit of repetition but pressing F8 at the right time prevented JS from defocusing the element.
If you are having problem selecting the element, you can try cmd + shift + c on Mac to select the element without right clicking it.
If its DOM manipulation problem, you might try to force state on the input element by right clicking on the element in the Elements panel and set force state to focus.
Open the docked DevTools first (the undocked approach will not work due to the OS limitations.)
Once the autocomplete box is displayed, right-click it and select "Inspect Element" in the context menu. The focus will move to the DevTools but the autocomplete box will still be shown (this worked for me on Linux, tip-of-tree Chromium, M25. Your mileage may vary.)
/**
* Utility to freeze actual DOM state, for example dropdown menu
*/
function easyBreak() {
function doBreak() {
// put breakpoint here to freeze actual dom and write to console easyBreak()
// you have 3 seconds to get to desired state
var a = 0;
}
window.setTimeout(doBreak, 3000);
}
You could use DOM breakpoints.
I'm having a similar case here : I want to inspect dropdown items that only show when the input has focus.
On Chrome, I right-click on the parent element and choose Break on > Subtree modifications.
It will pause - like it does with JS breakpoints - anytime the DOM changes within that parent. You can then inspect the children while the DOM is frozen.
I have a page with "main tabs" which behaves as follows;
1. On hover of these, I show "sub tabs"
2. On click of any of the main tabs, it goes to one of the default sub tab pages.
$(".mainlink_href").mouseover(function(){...}
Now these behaves as expected on desktop browsers. But on the iPad, when user clicks on any of the main tabs, it always does the hover method execution i.e. shows the sub tabs and does not go the sub tabs page (as in the desktop)
Now I agree, that this is as per expected iPad behavior since there is no mouse cursor to track for hover event otherwise...
But is there any way that I can update the code such that "only for the iPad" it does not go through the hover method for the first click and instead does the click event and directly takes the user to the default sub tab page (i.e. similar to point 2 above in desktop browsers)
Please help me. Thank you.
You could just assign both event handlers, and have the ontouchstart handler remove the onmouseover handler.
$(".mainlink_href").mouseover(function(){...});
$(".mainlink_href").ontouchstart(function(){this.mouseover=function(){};});
I have I'm using the dsmoothmenu jquery plugin to generate a toolbar on the top of my page -- About a month ago, the page started loading (most of the time) with the first item of the menu bar exposed -- as if the user were hovering over the item. I've spent hours trying to figure out what's causing this and haven't made any progress.
I have another page which uses the same exact markup for the menu, and the same dsmoothmenu js/css, but which doesn't exhibit the aforementioned behavior. So I figure it's got somehting to do with perhaps a meta tag, or a style that's being overwritten. By investigating with the inspector, it seems as though the ul#other_cities element is being given display:block by something, which is overriding the default style of display:none, which should be active until the user hovers over the element.
Here's an an example of the problem: http://www.foodtrucksmap.com/la/
And a working example: http://www.foodtrucksmap.com/iphone.html
EDIT: So I've found that the problem will only manifest itself if the mouse is OUTSIDE of the window when the page finishes loaded. If you keep the mouse hovering over the page, the menu bar will not slide down. This along with the fact that it only seems to happen in chrome, leaves me really confused.
I can see your problem in Chrome when I right-click the link and then "Open link in new tab" or " ... new window" which opens the window in the background. This leaves me with this conclusion.
Google's Chrome, for some weird reason, positions a "virtual" pointer at position top:1, left:1 which triggers the script. As soon as we bring in the actual "physical" pointer this position takes over and the problem is gone.
As this seems to be a problem with Chrome we can prevent this only with a little trick. I'd say we give the main div#wrapper some breathing room to the left with a margin? Or maybe something to the top like the second example which works!!!
So far I've been able to find out that the onMouseOver event actually fires when the page is loaded.
Since I don't have direct access to the JS files search for the word 'trigger' in all the file (not the jquery ones) and try to find out if it might be calling that at any point.
I will do more research when I have time.
If Nicklas is correct and hover is for some reason firing onload, try wrapping the js of the hover function in your menu javascript with the following conditional:
if(event.target == this) { //Check if the hover event actually targets the object.
//Hover Code//
}
Hope this helps!