start.me - start-page right-click context menu fails to render and locks-up all scrolling functions Topic is solved

[Pallid Planetoid]

Website: palemoon.startme

Off-topic:
The first thing I do on "milestone" releases is to check the websites that have not worked on Pale Moon up to that time (which led me to the issue with start.me - as I was removing link "warning not to use" text for websites that have apparently been fixed).

On a side note: safeway (safeway.com) still fails to login and Social Security (https://secure.ssa.gov/myssa/myhub/ still renders a blank page after submitting security process), however other sites (so far) appear to now work (i.e. Savemart [entire page appears to render correctly], CVS [images now display) so some good thankfully, but still some bad....

To the topic:
As the subject states - if I do a right-click context menu (to edit any link in any widget) the scrolling function for the page is disabled (there is a flash of the page and then all "scrolling" become disabled). Both the browser scroll function on the left of the page as well as mouse (middle button) scrolling functions fail to work). Fortunately, I can click on anything on the page however and the scrolling function once again works.

So what it comes down to is the right-click context menu edit functions are unusable (in fact the functions, list of edit options, does not display at all). The fact the right-click function list of edit features fails to render (resulting in a scroll function lockup) suggests that because there would appear to be an issue with Pale Moon displaying the right-click menu of edit options this failure to render the edit option list locks-up the scrolling function. Fortunately doing anything else reinstates the scrolling function.

There is another option to edit llnks in Widgets (but is not as convenient), because this other method involves accessing all the links so the convenience of simply editing the one link via using the right-click context menu to edit the one specific link is unfortunately no longer available do to this issue with (presumably) this new release.

I will add, that I can't say for certain at what point this issue may have arisen - as I don't edit links that often (needed to do so now to change the text for the link to remove warning messages to not use links that didn't previously work prior to this milestone release). So I can't actually be that certain when exactly this issue first arose (as I have probably not used the right-click context menu throughout many past Pale Moon releases).

If anyone has not yet updated to the "Milestone" release - please test the right-click (edit) context menu for Widget links, BEFORE UPDATING to see if it works!!!!!

[Moonchild]

32.5.2 also displays this issue. I'll write to start.me about this

[Pallid Planetoid]

Thanks Moonchild! - this issue only occurs with Pale Moon, btw.

And I would add my other topic (re: start.me) recently posted: Can anyone help out that uses start.me is also unique to Pale Moon as well.... hint, hint (and something that has occurred in the past, both times specific to only Pale Moon)

[Kris_88]

CSS Clamp() is not supported by PM.
You can try userContent.css to partially work around the problem.

Code: Select all

@-moz-document url-prefix(https://palemoon.start.me/) {
  ul.unified-menu__container { top: 200px; }
}

[Pallid Planetoid]

^ That CSS code resolves the posted issue - thanks!

... to partially work around the problem.

ahm, I don't see any problem; 1) context menu renders, 2) can be used and 3) scroll-bar is only locked-up while context menu displays, i.e. scrolling is functional after context menu is dismissed, which is probably the way it is supposed to work as far as I know - just curious, what is meant by "...to partially work around the problem."?

... or is what you mean by using the word "partially" (as in "temporary" solution) --- which is to say, use the CSS code up until the time when the issue is "officially" addressed at which time the CSS code would no longer be required?

[Pallid Planetoid]

It's obvious the reason the scrolling function fails to work is because this is what (normally) occurs while the right-click context menu is used (while in this case it is not getting displayed, which is the "root" of the problem) requiring any other "new" action by the user to dismiss the (not displayed) right-click context menu which then allows the scroll function to once again work (which would also be the case if in fact the context menu did display). ...Deductive logic at work...

In other words, it is expected that the scrolling functions will not perform during the time the right-click context menu is in use (albeit - in this case, fails to display). However, because the context menu does in fact fail to display it appears there are two issues, i.e. the failure to render the right-click context menu as well as the loss of the scrolling functions, when in fact it all comes down to the issue is limited to the failure of the right-click context menu to display in as much as the scrolling functions are doing what they "normally" do when the right-click context menu is in use, regardless whether or not the context menu actually is displayed. Which is why any action by the user while this issue exists reinstates the function of scrolling in as much as the action by the user serves to dismiss the "hidden" (so to speak) context menu (as would be the case if the context menu were displayed as well).

[Kris_88]

just curious, what is meant by "...to partially work around the problem."?

The context menu is displayed, but not at the mouse click coordinates. The menu works for the item you clicked on, but it doesn't appear where it should.

[Pallid Planetoid]

^ Hmm, it appears to me that the right-click context menu gets positioned in alignment with the link intended to us the menu (the links are pointed that I'm using the right-click context menu on). First context menu example appears to be aligned with the link that is intended to us the menu toward the top of the widget and the second context menu example is aligned as well with the link that is to use the menu toward the bottom of the widget.
EXAMPLE ONE:

PIC-1 Doug Ross link location.png

It seems that the context menu location is aligned in the vicinity of the widget where the "Doug Ross" link location is that I used the right-click context menu on.
EXAMPLE TWO:

PIC-2 Labcorp login link location.png

And it appears the context menu location in this case is aligned in the vicinity of the widget where the "Labcorp Login" link is located in the widget that I used the right-click context menu on.

The amount I scrolled down to do the second test compared to the first test can be determined by the same links that correspond to one another for each of the two screen-shots.

Am I missing something?

The context menus appear to me to be reasonably aligned with the links using the context menu. Frankly, I can't see how the menus could be aligned any better (than they are) to the link clicked-on that is to use the context menu), even the scroll-bar gets triggered in EXAMPLE 2 that is required to access the entirety of the context menu due to the lower location of the context menu on the page (that aligns with the link using the menu).

[Kris_88]

U18.png

[Pallid Planetoid]

OK, I see - but then it still does not appear that I've got the same problem:

PIC-1 menu location.png

PIC-2 menu location.png

[Kris_88]

Then I don't know. Perhaps the difference is that you are registered and I am not...

[Pallid Planetoid]

Probably...