These links at the top of the forum seem to be dead/404. Have they been moved or is this temporary?
http://i127.photobucket.com/albums/p145/wakou/suseforum_zpsbadbjacb.png
http://i127.photobucket.com/albums/p145/wakou/suseforum1_zpstwofrmle.png
I am not seeing those links.
Okay, I guess they are there if I am not logged in (I just tested in a private window in firefox). I am not seeing them when logged in.
That’s probably a bug. Somebody forgot to fix the page that people see when not logged in.
It is strange, but I am not seeing them also. I see the gekko in a black bar and the Search field at right. Then below it are a few empty rectangles. When I hover over them, I see those links!
AND, when I enlarge the window to full screen width, I see what the OP reports above. Maybe you can try the same.
Using those links gives the error 404. When you read the error message carefully, it is even worse. Not only is the page/file not found by the apache server, but the server is also configured to send an error page when such a thing happens. Not uncommon. But even that error page can not be found by the server. >:)
Thus we have a few things here:
- some pages (and not the most obscure ones) can not be found on the server;
- the server is configured to show an error page in case of problems, but that page is also not available;
- the HTML send to the browser is not displayed properly when the window that has to accomodate is is smaller then a certain (but not expremely small) width.
If you “right-click” “Downloads”, “Support”, “Community” or “Development” then, you’ll get “Error 404”.
If you “left-click” the things, you’ll be presented with drop-down lists which do work.
“Forum”, “Articles”, “Blogs” and “What’s New?” all work with “left-or-right click”.
[HR][/HR]Someone could request that a change be made to the “right-click” behaviour of the “Error 404” list by means of a Bug-Report.
I use middle click in my FF, which should open it in a new tab. It gives the 404.
When I left click on a members name in a post, I get a menu. When I middle click on the same, it will load the first item of the (not shown) menu: proifle. I assume that it should work the same on the items above.
Considering this also means that the experience for people using noscript is broken, this might warrant some fixing, either by setting the href attribute to #, or by creating a sitemap page.
Unless the web page code has changed since last post,
I just checked, using a browser logged in and a different browser not logged in,
And all links work.
Am not running noscripts, but am running ghostery on all browsers.
Additional:
Am able to re-produce the error in an incognito (or private window in FF) window in Chrome.
So, this issue does seem to be related to script blocking on the Client.
The Forums software people should know that they should implement AJAX and implement the script code server-side.
TSU
As so often, the problem is what “works” means. Most of the time things “work”. Maybe not as intended by the designer. Maybe not as expected by the user. Thus exact description of what is done and what is experienced is eminent.
When you hover over one of the items under scrunity (e.g. the Download), they show a cursor that gives you the idea it is a hyperlink.
When you “left click” on it, it does not load a new page (and thus is not a hyperlink), but gives a scroll down menu and the links there are real hyperlinks and load the pages that most people will expect.
But, when you have a browser that has the feature to “middle click” and/or “right click” on a hyperlink, loading the page in a new tab or new window of that particualr browser, that will give you the error 404 (Not Found) as reported.
So, you need:
- a browser that supports “open in new tab” and/or “open in new window” in some way
- and use that feature
I can not read from your post if that is what you did.
Actually,
AFAIK these mouse events can all be specified by the web page code, and are typically in the library used to ease the burden on the Developers.
Since this appears to be not supported properly by the library,
IMO it’s then the burden on the Developer to code the event.
So, more specifically the Forum software probably makes the navigation bar available as a drop-in component so that end Developers like openSUSE should only need to fill in the labels and wire up the backend, but the library apparently has a defect which this thread has discovered.
TSU
The problem is, of course, mark-up on the web page itself, not a browser error. The implementation was either not properly tested for alternate clicks, or the (quite common) practise of right-clicking to open links in new windows or tabs did not come to mind for the person who was doing the mark-up.
In any case, it is an error – probably of oversight – that should have been fixed long ago.
This is not the first time it has been brought up and discussed, as it is also in this thread:
https://forums.opensuse.org/showthread.php/519546-Button-Links-Broken-in-Forum
If you mean by the above that the developers of the vBulletin package did not program this in a proper way, you are coming to the same conclusion as the forum staff did. The technical staff will (or did already) bring this to the attention of the vBulletin people. But I do not think that a quick repair will be the result.
When you think you can be of any thechnical help to the vBulletin people, then please go there. Here we can not do very much with all the above.
Yes,
If as I have assumed that the menu bar is from vBulletin and not from somewhere else then it’s a vBulletin issue.
And, if anyone wants to bug the vBulletin people, short of writing some rt-click code the solution should be as I described in my earliest post, which is to implement AJAX so that instead of trying to execute the code client-side, the menu bar code is executed on the Server and passed to the client with any possible modifications in ordinary HTML.
TSU