Pop-up menu on discover.manjaro.org does not work Topic is solved

[palem]

Pop-up menu (in the top-right corner) as shown below does not work both in Pale Moon and in Basilisk on https://discover.manjaro.org/

[Moonchild]

Yeah people still don't understand that anything you place -inside- of a <button> tag is display content only. Click events will be captured by the button. They need to use buttons as buttons (and handle the clicks on the button element), or not use <button> elements to begin with if they want contained elements to be interactive.

[JustOff]

Pushlog: ac7f3be - 6f21533
Suspect: bug #1089326

Blink ate them all ...

[Moonchild]

I don't care what the pushlog is and what Mozilla did to go against design logic. It's just wrong to change this behavior.

[palem]

I'm not an expert to decide how it should be done, but as I tested, it works on Firefox, Chromium, Opera and Brave.
And does not work on Pale Moon and Basilisk only.

[Moonchild]

I'm not an expert to decide how it should be done, but as I tested, it works on Firefox, Chromium, Opera and Brave.
And does not work on Pale Moon and Basilisk only.

You're saying it works in Firefox (because they decided to follow Chrome), Chromium, Chromium and Chromium.

It's just wrong. A <button> is not a generic content container. It is a button and acts like a button. Anything placed inside of it is UI (display) only. If you'd foolishly nest <button> elements then as is logical any click on it will end up with the event target being the outermost button element.

FTR: this was specced in HTML4. It's an HTML4 element. They didn't word it as explicit in html5, Chrome/webkit decided to deviate against everyone else. IE agrees with us. Opera Presto also. Just the 5 flavors of Chrome don't.

[RoestVrijStaal]

You're saying it works in Firefox (because they decided to follow Chrome), Chromium, Chromium and Chromium.

It's just wrong. A <button> is not a generic content container. It is a button and acts like a button. Anything placed inside of it is UI (display) only. If you'd foolishly nest <button> elements then as is logical any click on it will end up with the event target being the outermost button element.

FTR: this was specced in HTML4. It's an HTML4 element. They didn't word it as explicit in html5, Chrome/webkit decided to deviate against everyone else. IE agrees with us. Opera Presto also. Just the 5 flavors of Chrome don't.

Off-topic:
Thanks for clarifying this.

And for the future I'll link every person who states that Firefox / Chromium is correctly following the W3C standards.

[palem]

it works in Firefox (because they decided to follow Chrome), Chromium, Chromium and Chromium.
It's just wrong.

Yes, you are right in saying that (at the moment) it's wrong but ...

Chrome + Firefox has almost 80% in the browser market share. So (although we may not like it), these two browsers, by introducing some new solutions, are creating new trends that other browsers should also implement - in their own interest.

PM is my favorite and main browser and I wish all the best for it. Therefore please consider to implement a solution, so that PM (like the dominant 2 browsers) will properly support the pop-up menu from this thread (and on other similar websites).

[New Tobin Paradigm]

Should we also get rid of the Mozilla Extension technology and go WebExtension only, have an almost unchangeable UI, and change all dialogs to web pages like them too?

[palem]

@New Tobin Paradigm
You asked a very important question.
IMHO, as long as XUL extensions are available and working, there is no urgent need for WebExtensions.
However, as you can see, more and more XUL extensions stop working, and developers - unfortunately - do not develop them, which makes PM less functional for some people (and I even know a few people who have resigned from PM for this reason ).

So the time will come that PM developers will have to decide what to do with the extensions.
I think a good solution would be a hybrid solution, similar to what was once in Basilisk - for PM to work with both XUL and WebExtensions (although I realize this is a lot of work for PM developers).

[New Tobin Paradigm]

We will never give up our inherited technology and pretty much any Firefox extension can be made into a Pale Moon extension. I think you fail to see the bigger picture or what we are out to accomplish.

[Moonchild]

So (although we may not like it), these two browsers, by introducing some new solutions, are creating new trends that other browsers should also implement - in their own interest.

There is a problem if these "trends" are not about new features but changing existing ones against previously established standards.
There is also a problem if these "trends" are rooted solely in the vision of one company's implementation that others will just "have to follow" because they have the largest market share, regardless of reason or logic.
Also, what you're implying is that we should just become exactly like whatever the biggest browser market share holder is like, in every feature, or be "irrelevant". Well then, why would there be the choice of browser anyway in that case, if every alternative should strive to be -exactly like- the biggest share holder? In that case we may as well not do this because we've seen, painfully so, what becoming a cheap clone of the market leader does to your own market share and brand individuality (i.e.: Mozilla Firefox)

[palem]

what you're implying is that we should just become exactly like whatever the biggest browser market share holder is like, in every feature, or be "irrelevant".

Absolutely not. PM (at least for me) has its advantages and does not have to copy all the features of the dominant browser.

But PM should implement solutions without which it will be a non-functional browser (e.g. unable to open the menu shown in this thread).

[New Tobin Paradigm]

Or maybe alternative open source operating system projects should embrace and support alternative open source browser projects.

Didja think of that?

[Moonchild]

But PM should implement solutions without which it will be a non-functional browser (e.g. unable to open the menu shown in this thread).

No, it should not.
It should not implement solutions that go directly against previously-established standards and against logic.
What should be done is that web designers be browser-agnostic, especially those of fellow Open Source projects, and even more so for design decisions that are using standards-breaking quirks of proprietary software, no matter how often the vendors of that software tell you otherwise.

You don't care about other features perhaps, and only care about this website... but others do. For you it's this website. for someone else it might be something else on another website, and so on, and so forth.

See https://bugzilla.mozilla.org/show_bug.c ... 089326#c29 and surrounding comments. That was in 2015 -- that has not changed, and the current WhatWG spec is also ambiguous as to what is supposed to happen; actually even more so since the "authentic click activation steps" have, AFAICT, completely been removed from it.

The root of the problem is that the description for the <button> element designates that the activation target of a click on a <button> is always the button itself, because it acts like an "input" element, with the difference that it can have content -- however that content should only be "phrasing" content (i.e.: not interactive); e.g. the html4 spec explicitly forbids IMG contents with image map interaction inside a button, so the spec it pretty clear it's only for display purposes -- see also https://developer.mozilla.org/en-US/doc ... ng_content about phrasing content restrictions. Chrome (and in turn recent Firefox too once they decided to just follow Chrome's lead for this as well), however, might have this target be any descendant of that button, and that is simply wrong. As stated before it's not a generic container element -- these elements are different elements for a reason and should not be watered down to be generic containers. Too often that is already being done. A button is a button, should act like a button and nothing but a button.

Think of it this way: If you have a physical button that has the word "eye" printed on it; if you press that button, are you then poking an eye, or pressing a button?
Chrome says you're poking an eye. We say you're pressing a button, regardless of how it's labelled.
If you don't want that to happen, then don't use <button> which is exactly there for this very behaviour of "pressing a button".

Unfortunately I've learned from past interactions that bringing this up with Chrome devs is futile, since their implementation is always "golden" no matter if it's wrong. Bringing it up with Mozilla seems to be just as futile if they have decided to align with Chrome (as is the case here). So what can we do? try to educate webmasters in proper use of HTML, and not much else, I'm afraid.

[illiad]

Has anyone tried it in win 10 edge? also how many people use that website out of **the whole world**

Note: PM me if I and drifting of topic.. we are talking about why the OP website is a problem or not??? ( and a bit of background history)
[also names changed to stop bad search bots...]
go back 10 years or more, AFAIK it was goggle who mainly supported FF, by fiddling code, letting thru lots of 'bad' code stuff, so that its new gmail would work and and get them $$$..
the reason they succeeded, was FF was given away by the billions, getting a good name.. and youngsters today don't even realize that today's browsers have ***nothing** to do with 10 years ago...

[palem]

Website https://discover.manjaro.org/ has been changed and the issue no more exists there.
So the problem (considering this website only) is solved.

[Moonchild]

So the problem (considering this website only) is solved.

It's a simple mistake and a simple fix. If website owners, when alerted to this, aren't fixing this then they are really not doing their job of keeping their site accessible.
FYI: I reported the same problem on a different website I happen to have an account with since recently and their dashboard having the same problem. Sent an explanatory e-mail, and it was fixed in 15 minutes.