"articles" menu is unusable
-
It works fine for me too: on both my desktop Win10 / Chrome, and the WookieTab Win10 / chrome tablet, all running the latest versions of OS and Chrome. It also works fine on my Android tablet / Chrome. This may sound like a silly question, but have you tried it with a different mouse and driver after a fresh boot? If it works on a touch tablet and mouse desktop it's a little odd that it doesn't work on your system. What happens if you try on your phone? It works fine on mine, in both mobile and desktop view.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
I honestly don't see how the mouse driver would be the issue at all here, it is being rendered inside the browser, not on the OS; but no I have not checked on my phone or tablet, I suppose I could. But touch on those devices and mouse on desktop should not be behaving dramatically too different, just optimizations are different for xy coordinate targeting. EDIT: I tried it on mobile and not surprisingly, it doesn't behave in "scroll" mode on that, it is tap to expand, therefore moot and will not behave as observed for reasons that involve not capturing mouse movement as extensively discussed above. So, comparing to mobile/touch based is not going to be a valid comparison. Finger/touch do not behave the same as Mouse/scroll.
-
MY guess is that it's the
left:100%CSS directive that is meant to place the flyout menu to the exact right of the dropdown menu, but I don't know why it's an issue on your machine and not others'. Maybe some regional settings. I asked for the other info just to doubly ensure there wasn't something else. There's been many times I've tried to diagnose something only to find out an ad blocker is causing the issue, or a firewall is blocking a javscript file from loading.cheers Chris Maunder
I have the same issue. On chrome Version 63.0.3239.132 (Official Build) (64-bit) (also in incognito window so no plugins or anything) On firefox 57.0.4 (64-bits) On Brave (yeah I even tried it there ;P ) On IE version 11.192.16299.0 Works as should on Edge tho. Tried it on different resolutions (no change) No errors in console. If you need me to test / try anything let me know. [Update] I don't have it at home (unless you changed something already) [/UPDATE]
Tom
-
Currently when you hover on the "articles" menu, you cannot ever click on any item on it because the first item "chapters and sections" will always trap as the first item that automatically expands to replace the menu and so you can never reach any of the child items on the "articles" drop down. It should either have a hover timer (meaning if you hover over that item for x[ms] expand it) or make it click to expand to avoid having it trap all mouse movement and preventing access to any of the other child items on the menu. Alternatively, move it to the bottom of the list as to make it non-blocking on all other items.
How is it now?
cheers Chris Maunder
-
How is it now?
cheers Chris Maunder
Still on my daily driver (Firefox 56) it will not allow me to go any further down because the first one flies out and replaces the menu and pretty much traps the movement. Nothing has changed there. On Edge, it works fine, but not my daily driver. In Chrome (62) it did the same thing but in (64) it works fine, used exclusively for testing. I had one of our Mac users test on Safari, same thing, and another user on Vivaldi and Opera, same thing. Not sure what else I can provide to help. Let me know if you think of something.
-
Still on my daily driver (Firefox 56) it will not allow me to go any further down because the first one flies out and replaces the menu and pretty much traps the movement. Nothing has changed there. On Edge, it works fine, but not my daily driver. In Chrome (62) it did the same thing but in (64) it works fine, used exclusively for testing. I had one of our Mac users test on Safari, same thing, and another user on Vivaldi and Opera, same thing. Not sure what else I can provide to help. Let me know if you think of something.
Can you try Ctrl+F5 to force a full refresh. I'm at a loss here. I've changed the CSS from the more elegant (left:100%) to forcing the position at the pixel level (left:208px). I've only ever heard of one other who has been affected. If I could replicate it I could at the very least disable the flyout menu. On every single machine and browser I've tried it's always worked. There has to be something unusual about your setup. Regional settings, maybe some CSS is being stripped by firewalls or blockers (maybe they are upstream of you? If there's anything odd or non-standard about your setup let me know and I can try coming up with a plan C
cheers Chris Maunder
-
Can you try Ctrl+F5 to force a full refresh. I'm at a loss here. I've changed the CSS from the more elegant (left:100%) to forcing the position at the pixel level (left:208px). I've only ever heard of one other who has been affected. If I could replicate it I could at the very least disable the flyout menu. On every single machine and browser I've tried it's always worked. There has to be something unusual about your setup. Regional settings, maybe some CSS is being stripped by firewalls or blockers (maybe they are upstream of you? If there's anything odd or non-standard about your setup let me know and I can try coming up with a plan C
cheers Chris Maunder
Quote:
Can you try Ctrl+F5 to force a full refresh.
Ok, caching is not the problem here, not even close. But done, even recorded for you to watch. Look at how it happens.[^]
Quote:
I'm at a loss here. I've changed the CSS from the more elegant (left:100%) to forcing the position at the pixel level (left:208px).
You can clearly see it replaces the menu, it is not positioning that's the issue, I am watching the DOM and it replaces it. I have been tracing the computed styles on that object and it always reverts to 0 which means it will "replace" the original menu, rather than fly out to the right of it. Not sure why, I didn't go digging through your CSS files or what is being inherited where or how the object is being delegated for it.
Quote:
On every single machine and browser I've tried it's always worked. There has to be something unusual about your setup. Regional settings, maybe some CSS is being stripped by firewalls or blockers (maybe they are upstream of you?
Ok, here's the problem I have with that logic, it is not the network, it is not extensions, it is not upstream. If it was any of that, it would happen in every browser on the same machine/network, not just specific ones (or different versions of the same browser). Additionally, as I have said repeatedly, it happens in a clean, freshly created, stock, no extension, nothing profile and on 3 separate networks, home, work, and mobile hotspot. You can see it happen, it is not something I am imagining here.
Quote:
If there's anything odd or non-standard about your setup let me know and I can try coming up with a plan C
Nothing odd or non-standard about my setup, in fact I abhor having too many extensions and things that limit a clean experience. I may not go willy nilly with installing a ton of crap, but that is hardly odd or non-standard behavior, I am a purist and have worked nearly 30 years to keep it that way. If I didn't care about the site, I wouldn't bother with the time and effort to report it. While it may very well be an edge case, it IS happening and if it is happening to me, it is happening to others, even if only one other person took the time to report it to
-
Quote:
Can you try Ctrl+F5 to force a full refresh.
Ok, caching is not the problem here, not even close. But done, even recorded for you to watch. Look at how it happens.[^]
Quote:
I'm at a loss here. I've changed the CSS from the more elegant (left:100%) to forcing the position at the pixel level (left:208px).
You can clearly see it replaces the menu, it is not positioning that's the issue, I am watching the DOM and it replaces it. I have been tracing the computed styles on that object and it always reverts to 0 which means it will "replace" the original menu, rather than fly out to the right of it. Not sure why, I didn't go digging through your CSS files or what is being inherited where or how the object is being delegated for it.
Quote:
On every single machine and browser I've tried it's always worked. There has to be something unusual about your setup. Regional settings, maybe some CSS is being stripped by firewalls or blockers (maybe they are upstream of you?
Ok, here's the problem I have with that logic, it is not the network, it is not extensions, it is not upstream. If it was any of that, it would happen in every browser on the same machine/network, not just specific ones (or different versions of the same browser). Additionally, as I have said repeatedly, it happens in a clean, freshly created, stock, no extension, nothing profile and on 3 separate networks, home, work, and mobile hotspot. You can see it happen, it is not something I am imagining here.
Quote:
If there's anything odd or non-standard about your setup let me know and I can try coming up with a plan C
Nothing odd or non-standard about my setup, in fact I abhor having too many extensions and things that limit a clean experience. I may not go willy nilly with installing a ton of crap, but that is hardly odd or non-standard behavior, I am a purist and have worked nearly 30 years to keep it that way. If I didn't care about the site, I wouldn't bother with the time and effort to report it. While it may very well be an edge case, it IS happening and if it is happening to me, it is happening to others, even if only one other person took the time to report it to
GµårÐïåñ wrote:
You can clearly see it replaces the menu
Actually I don't see that it replaces. The menu. It seems it places the section menu on top of the article menu, but doesn't replace it. If you're game could you do me a favour? In the dev tools of any browser you can drill down into the source. Starting at the "articles" header of the menu (1) go the the Chapters and Sections (2) as you have been then check out the CSS of the taxonomy flyout with id ctl00_TopNavBar_MapFlyout (3). Let me know what the CSS for the 'left' attribute is for that element (4)
cheers Chris Maunder
-
GµårÐïåñ wrote:
You can clearly see it replaces the menu
Actually I don't see that it replaces. The menu. It seems it places the section menu on top of the article menu, but doesn't replace it. If you're game could you do me a favour? In the dev tools of any browser you can drill down into the source. Starting at the "articles" header of the menu (1) go the the Chapters and Sections (2) as you have been then check out the CSS of the taxonomy flyout with id ctl00_TopNavBar_MapFlyout (3). Let me know what the CSS for the 'left' attribute is for that element (4)
cheers Chris Maunder
-
I will absolutely do that for you, just wanted to acknowledge I got your request; but I won't be able to get on this until later in the day but I will post it as soon as I get home. Didn't want you to think I left you hanging, thanks.
There's no rush: whenever you get a chance.
cheers Chris Maunder
-
GµårÐïåñ wrote:
You can clearly see it replaces the menu
Actually I don't see that it replaces. The menu. It seems it places the section menu on top of the article menu, but doesn't replace it. If you're game could you do me a favour? In the dev tools of any browser you can drill down into the source. Starting at the "articles" header of the menu (1) go the the Chapters and Sections (2) as you have been then check out the CSS of the taxonomy flyout with id ctl00_TopNavBar_MapFlyout (3). Let me know what the CSS for the 'left' attribute is for that element (4)
cheers Chris Maunder
Ok, given that the term "replace" can have multiple interpretations, you are right, it doesn't replace it in code but by view. So let's call it obscure instead. I did a quick grab, before I leave work, of the same thing you did for you to see (FF56) and giving you the CSS broken down, as well as the computed entry for it. This way you can take a look and let me know what else I can provide to help when I get home.
-
Ok, given that the term "replace" can have multiple interpretations, you are right, it doesn't replace it in code but by view. So let's call it obscure instead. I did a quick grab, before I leave work, of the same thing you did for you to see (FF56) and giving you the CSS broken down, as well as the computed entry for it. This way you can take a look and let me know what else I can provide to help when I get home.
Thanks for this. I should have given you one more step: Can you make sure you're hovering over the "Chapters and Sections" menu item (the item that triggers the taxonomy fly-out) when taking the screen grab? (I use the Windows snipping tool and set a delay of a couple of seconds to I can get my cursor in place before the screenshot)
cheers Chris Maunder
-
Thanks for this. I should have given you one more step: Can you make sure you're hovering over the "Chapters and Sections" menu item (the item that triggers the taxonomy fly-out) when taking the screen grab? (I use the Windows snipping tool and set a delay of a couple of seconds to I can get my cursor in place before the screenshot)
cheers Chris Maunder
That was my first instinct and I thought I had done that, sorry. Here you go, this is while the mouse hovers over that menu section. Here you go, let me know if I can provide anything else (note, I used the space of both screens to capture as much of the css vertically as possible, so that's why it is longer this time)
-
That was my first instinct and I thought I had done that, sorry. Here you go, this is while the mouse hovers over that menu section. Here you go, let me know if I can provide anything else (note, I used the space of both screens to capture as much of the css vertically as possible, so that's why it is longer this time)
Thanks for that. The LI element containing the taxonomy flyout has, in your screenshot, the class "openable" but not "open". Was the flyout (the taxonomy menu) open?
cheers Chris Maunder
-
Thanks for that. The LI element containing the taxonomy flyout has, in your screenshot, the class "openable" but not "open". Was the flyout (the taxonomy menu) open?
cheers Chris Maunder
Don't know what to tell you, this is what I did (since I use Snipping Tool myself as well). 1. Open the inspect, 2. Select the element that is selected, 3. Trigger the timer, 4. Put mouse over the menu to open (briefly shows a bunch of newly added items in the inspector when ajax completes) 5. Screenshot is what you see So, I don't know why the class is openable instead of open but maybe that's part of the problem. But yes, the taxonomy flyout menu was open and if you like, I can take a screenshot that includes that part of the screen too in addition to the inspector, if it helps you. I just made this video of the steps for you to see it as it happens, as you can see the yellow blocks load the new flyout and they are all tagged openable instead of open even though clearly you can see I am going through it with my mouse and hovering to open them. Hope it helps [^].
-
Don't know what to tell you, this is what I did (since I use Snipping Tool myself as well). 1. Open the inspect, 2. Select the element that is selected, 3. Trigger the timer, 4. Put mouse over the menu to open (briefly shows a bunch of newly added items in the inspector when ajax completes) 5. Screenshot is what you see So, I don't know why the class is openable instead of open but maybe that's part of the problem. But yes, the taxonomy flyout menu was open and if you like, I can take a screenshot that includes that part of the screen too in addition to the inspector, if it helps you. I just made this video of the steps for you to see it as it happens, as you can see the yellow blocks load the new flyout and they are all tagged openable instead of open even though clearly you can see I am going through it with my mouse and hovering to open them. Hope it helps [^].
That video is excellent. Question: Are you using a touchscreen? I assume from the video you're using a mouse?
cheers Chris Maunder
-
That video is excellent. Question: Are you using a touchscreen? I assume from the video you're using a mouse?
cheers Chris Maunder
I am glad to help. :-O No, I am not using a touchscreen, a mouse, same as in the video (in fact that is the very system on which it happens and the very browser it happens in). Using touchscreen on Android tablet and phone, no issue, since there is no "hover" in that interface, you click, it opens, you select what you want. But on the Windows desktop using a mouse when you move it down (aka hover) to select something, gets snared by that flyout as you saw. Let me know anything else I can provide to help. I am happy to give you whatever you need to figure this out.
-
I am glad to help. :-O No, I am not using a touchscreen, a mouse, same as in the video (in fact that is the very system on which it happens and the very browser it happens in). Using touchscreen on Android tablet and phone, no issue, since there is no "hover" in that interface, you click, it opens, you select what you want. But on the Windows desktop using a mouse when you move it down (aka hover) to select something, gets snared by that flyout as you saw. Let me know anything else I can provide to help. I am happy to give you whatever you need to figure this out.
GµårÐïåñ wrote:
No, I am not using a touchscreen
Is the menu still showing problems (maybe a Ctrl+F5?). I've traced the issue, thanks to your incredibly helpful video, to the "open" class not being applied to the menu when you hover. Two things can stop this: the jQuery hover plugin not firing (if the user was using a touch interface or keyboard navigation) or if the browser thinks your system is a touchscreen (in which case our code failed to handle hover events - a mistake on our part). In either case I've changed the CSS so the menu should be positioned correctly. Should be, being the operative word. The hover stuff is there solely to allow us to keep the menu open for a few hundred milliseconds after the mouse exits the menu in order to make it less hair-trigger if you accidentally move your mouse out of the chapters menu while scrolling. If it's still not working then I'll start on plan C. Or D. Not sure where I'm up to at this point.
cheers Chris Maunder
-
GµårÐïåñ wrote:
No, I am not using a touchscreen
Is the menu still showing problems (maybe a Ctrl+F5?). I've traced the issue, thanks to your incredibly helpful video, to the "open" class not being applied to the menu when you hover. Two things can stop this: the jQuery hover plugin not firing (if the user was using a touch interface or keyboard navigation) or if the browser thinks your system is a touchscreen (in which case our code failed to handle hover events - a mistake on our part). In either case I've changed the CSS so the menu should be positioned correctly. Should be, being the operative word. The hover stuff is there solely to allow us to keep the menu open for a few hundred milliseconds after the mouse exits the menu in order to make it less hair-trigger if you accidentally move your mouse out of the chapters menu while scrolling. If it's still not working then I'll start on plan C. Or D. Not sure where I'm up to at this point.
cheers Chris Maunder
Quote:
Is the menu still showing problems (maybe a Ctrl+F5?). I've traced the issue, thanks to your incredibly helpful video, to the "open" class not being applied to the menu when you hover. Two things can stop this: the jQuery hover plugin not firing (if the user was using a touch interface or keyboard navigation) or if the browser thinks your system is a touchscreen (in which case our code failed to handle hover events - a mistake on our part).
Unfortunately, no it has not. I have done a hard reload, even disabled cache to make sure of it. You are welcome, glad it helped, I figured better to see it live than pictures to ensure we can observe the behavior best, glad it was helpful. I wish I knew why it is not triggering but I have ruled out touchscreen as the issue as this particular system is NOT touchscreen at all, which means there is no reason for the browser or anything to assume it. I even explicitly disabled OSK to ensure there is no trace of any misunderstanding by the browser. Alas, it still occurs. Honestly I can't even offer a reason at this point, all I can do is provide you everything I can to help in diagnosing it.
Quote:
In either case I've changed the CSS so the menu should be positioned correctly. Should be, being the operative word. The hover stuff is there solely to allow us to keep the menu open for a few hundred milliseconds after the mouse exits the menu in order to make it less hair-trigger if you accidentally move your mouse out of the chapters menu while scrolling.
Despite the change to trigger timer and the fact that there is no option to NOT hover over that item (it is not accidental, you have no choice but to hover over it as you try and reach other menu items) since it is the first item, it still entraps it. Unless the hover is longer so that the mouse can be moved very quickly to "beat" the trigger timer, it still entraps as before. I will try and modify the behavior as much as I can on the client-side using GM to try and see if I can "force" a delay on my end or alternatively temporarily neuter it (aka "defer" the behavior) so it allows hover past that item and I will share whatever "fix" or "hack" I can achieve with you to see if it can be translated to a server-side (aka your code) to mimic it or not. I'll keep you posted on that effort.
Quote:
If it's still not working then I'll start on plan C. Or D. Not sure where
-
GµårÐïåñ wrote:
No, I am not using a touchscreen
Is the menu still showing problems (maybe a Ctrl+F5?). I've traced the issue, thanks to your incredibly helpful video, to the "open" class not being applied to the menu when you hover. Two things can stop this: the jQuery hover plugin not firing (if the user was using a touch interface or keyboard navigation) or if the browser thinks your system is a touchscreen (in which case our code failed to handle hover events - a mistake on our part). In either case I've changed the CSS so the menu should be positioned correctly. Should be, being the operative word. The hover stuff is there solely to allow us to keep the menu open for a few hundred milliseconds after the mouse exits the menu in order to make it less hair-trigger if you accidentally move your mouse out of the chapters menu while scrolling. If it's still not working then I'll start on plan C. Or D. Not sure where I'm up to at this point.
cheers Chris Maunder
This may or may not be something but you might want to look into it and rule it out. I was running the debugger and setup breakpoints to catch the behavior as we go and came across this, thought I share.
TypeError: $(...).doubleTapToGo is not a function standard.min.js:1:15328
NavBarMenu/this.InitMenu https://codeproject.global.ssl.fastly.net/script/JS/standard.min.js:1:15328With the breakpoint at line 179 (aka ctl00_TopNavBar_MapFlyout) the menu positioning works as intended (yay) BUT as you can see, the display is offset and overlapping and a little messed up:
Just a quick share, onward I go... -
This may or may not be something but you might want to look into it and rule it out. I was running the debugger and setup breakpoints to catch the behavior as we go and came across this, thought I share.
TypeError: $(...).doubleTapToGo is not a function standard.min.js:1:15328
NavBarMenu/this.InitMenu https://codeproject.global.ssl.fastly.net/script/JS/standard.min.js:1:15328With the breakpoint at line 179 (aka ctl00_TopNavBar_MapFlyout) the menu positioning works as intended (yay) BUT as you can see, the display is offset and overlapping and a little messed up:
Just a quick share, onward I go...Excellent data point. Can you please try again?
cheers Chris Maunder
