|
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.
|
|
|
|
|
This has already been reported and I'm unable to replicate the issue. I'm on the latest Chrome, Safari, Firefox, Opera and Edge.
Do you have any ad blockers installed? What browser and version?
cheers
Chris Maunder
|
|
|
|
|
This has absolutely nothing to do with an adblocker and is very easy to replicate.
1. Hover over the "articles"
2. See the drop down list
3. move your mouse down to try and click on say "latest articles"
4. the first link expands (with a quick spinner) and you never make it further
I can reproduce it on Firefox, Chrome, Vivaldi, Safari, and Edge, both regular profiles and clean stock profiles with nothing installed.
Would you like me to capture a video of it happening and show you? This is pure and simple the way the menu behavior has been coded and since it is the first item, it simply captures all movements first.
|
|
|
|
|
GµårÐïåñ wrote: This has absolutely nothing to do with an adblocker
I need to check, OK?
GµårÐïåñ wrote: Would you like me to capture a video of it happening and show you
No, I believe you. I can, however, also show you a video of it working fine on my machine.
Can you help me out a little more:
- how is your internet connection? Fast, slow, reliable?
- If you hit F12 (or Ctrl-Shift-I) to bring up developer tools, do you see any javascript errors in the console?
- Do you have any add-ins installed in your browsers?
cheers
Chris Maunder
|
|
|
|
|
Quote: I need to check, OK?
Of course, that's why I reported it 
Quote: No, I believe you. I can, however, also show you a video of it working fine on my machine.
I have no doubt, but sometimes development machines/environments can put us in a false sense of proper functionality, try it as an end user with a separate machine, separate browser that you don't use for development and see if it still works right, that's all I can suggest.
Quote: Can you help me out a little more:
Certainly, be happy to.
- how is your internet connection? Fast, slow, reliable? Very fast, very stable. I am on a multiple T3 network with redundant OC3 backbone. But again, this is not the issue, the menu rendering is simple CSS and not that heavy to be an internet issue. At 3000+ kbps bandwidth, I can download an entire Linux distribution in less than 30 seconds.
- If you hit F12 (or Ctrl-Shift-I) to bring up developer tools, do you see any javascript errors in the console? Nope, absolutely nothing. Again, I am confident it is not an error but how it is coded in that it captures the mouse event, loads that particular expandable and replaces the main drop down menu, it is not failing to load or not loading making it a JS error or networking error, it is simply how the UI behaves. I honestly believe seeing it in action will help you, so I am going to link the MP4 and GIF showing it to make it more clear what I am seeing, who knows it might help.
- Do you have any add-ins installed in your browsers? Of course, who doesn't right  but again none of them would be messing with the page render, website's GUI, etc. and certainly not so much so granular to target this specific menu on this specific site. That's why I also tested it specifically in "stock" (meaning has nothing) profiles to ensure that there is no interference, not my first rodeo and still the same behavior.
Let me know what else I can provide to help but in the meantime, here is the link to the MP4 and GIF showing the observed behavior since I can't put them inline here (which you might want to look into providing some capability for that given the nature of the site) and also note that I am still not getting notifications for any of these replies, here or in the other thread - that issue still remains. I just happen to be on the site through out the day, so I see them.
Visuals MP4[^] / GIF[^] (I am including the video so you can pause and rewind since the gif will only give you a one way timeline)
|
|
|
|
|
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 understand, but not the case for me. As I said, I immediately tried it in a stock profile on Firefox first to make sure and then repeated it in every browser copy we keep for development and testing and it kept happening. I can't say for sure why it is happening, I suppose I can dig in the DOM code as it is loaded and see what's happening by debugging it, but figured your code might be easier for you on your end. If I discover something, I will let you know.
Edit: I have narrowed it down to being something within the Firefox 56+ browser: Quote: This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!
With that in mind, I decided to try it on a pre-webext ESR build and found that it worked fine there. On an insider build of Edge (instead of the current release where it was happening as well) and found that it doesn't occur there, meaning on Edge it expands normally and does NOT replace the original menu like you saw in the video. Running on Chrome 62 it occurs the same way but on the Canary build it did not occur. So it seems to be a conflict with some new standard they are pushing towards and it might be worth looking into, even though it may not be as widespread, it is still an issue worth nipping in the bud.
modified 19-Jan-18 16:39pm.
|
|
|
|
|
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  )
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
modified 23-Jan-18 12:29pm.
|
|
|
|
|
Did you ever get this fixed?
If so I'm afraid I have to report it's back.
If not, ignore this message
Tom
|
|
|
|
|
I did. It was fixed perfectly. Then it stopped working again. I found the issue this time and will deploy probably tomorrow.
cheers
Chris Maunder
|
|
|
|
|
Looks fixed
Tom
|
|
|
|
|
For now
cheers
Chris Maunder
|
|
|
|
|
Just for the record I have never seen this problem on my PC using the latest version of Chrome, or on my iPad with Safari. The articles dropdowns all work and expand (or not) as expected.
|
|
|
|
|
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.
modified 19-Jan-18 16:42pm.
|
|
|
|
|
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.
|
|
|
|
|
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 you. Not having reports doesn't mean it is not happening, it is a false conclusion to draw that all works well everywhere because no one said anything about it. Most people don't care, move on and find it elsewhere.
Anyway, if there is a way I can help, as you can see clearly, I am fully game. However, let's be clear, I have eliminated everything suggested outside of the browser and even most of what is within the browser, so it is either the way the render engine is interpreting it, after all ASP on Mozilla, not exactly two peas in a pod but I have developed extensively in ASP (both classic and .net) so I know that in itself it means nothing that they are different. But it is something to look into as to how the code is being rendered by ASP versus how the browser interprets it.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
