Problems with the actualization 31.4 Topic is solved
Moderator: trava90
Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
Problems with the actualization 31.4
Hi, in new version 31.4, When you press the delete button the window goes back to the last one you was.
And When you press the buttot on top of Cap Lock (tab button) the selector goes to the searching bar on the top of the window.
¿Is that normal ?
Windows 10:
31.4:
32-bit or 64-bit browser:
And When you press the buttot on top of Cap Lock (tab button) the selector goes to the searching bar on the top of the window.
¿Is that normal ?
Windows 10:
31.4:
32-bit or 64-bit browser:
Last edited by AlexBrainbond on 2022-11-23, 16:06, edited 1 time in total.
Re: Problems with the actualization 31.4
Please give a full description of the problem. Without nobody could and will help you.
See: IMPORTANT: Information to include when asking for support
See: IMPORTANT: Information to include when asking for support
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
Re: Problems with the actualization 31.4
When you are writing on a text input on one page but u want to delete the text, you press the delete button on your keyboard.
But the text is not removed.
When you press the delete button, the page you are viewing, goes to the back page you was.
But the text is not removed.
When you press the delete button, the page you are viewing, goes to the back page you was.
Re: Problems with the actualization 31.4
Tools | Preferences -> Close the window when the last tab is closed (uncheck)
Re: Problems with the actualization 31.4
I'm assuming you're talking about "backspace" here which, if you do not have a text input focused, is a shortcut key for navigating back in history.
Can you please provide a URL?
Can you please provide exact steps to reproduce the issue?
Can you please provide a URL?
Can you please provide exact steps to reproduce the issue?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- MoonWalker
- Apollo supporter
- Posts: 31
- Joined: 2020-10-13, 15:38
Re: Problems with the actualization 31.4
Looks like you are having trouble with shortcuts. Backspace key is a shortcut to go back to the previous page. That shortcut does not work when the cursor is active in a text box, but if you click in any place outside the text box and then press backspace, you will activate the shortcut.
And Ctrl + L is a shortcut to place the cursor on the address bar. You are probably press Ctrl instead of cap lock or tab.
And Ctrl + L is a shortcut to place the cursor on the address bar. You are probably press Ctrl instead of cap lock or tab.
Re: Problems with the actualization 31.4
We had a behavioural change this version to no longer fire keypress events for non-printable keys (so they are naturally handled by first content scripts and if unhandled, by the browser itself) so it is possible that any non-standard handling of input that is not an editable form or element no longer catches the keypress (and potentially not firing a preventDefault() as a result) if listening on keypress events, and it filtering up to the navigation instead.
We would need to know if this is a plugin issue or where it exactly occurs to reproduce and investigate, but could you please let us know as well if setting dom.keyboardevent.keypress.dispatch_non_printable_in_content to "true" helps, to confirm this is the issue, as well as more details?
We would need to know if this is a plugin issue or where it exactly occurs to reproduce and investigate, but could you please let us know as well if setting dom.keyboardevent.keypress.dispatch_non_printable_in_content to "true" helps, to confirm this is the issue, as well as more details?
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
Re: Problems with the actualization 31.4
It is an Aplication on cloud and it was made on FLEX, it isn't a normal form.
We have got 2 apps 1 on Flex(it doesn't work) and the other on Angular (it work well).
I think the language "FLEX" is the problem.
I can't provide one URL because you need a user and password to use it because is an Online ERP.
We have got 2 apps 1 on Flex(it doesn't work) and the other on Angular (it work well).
I think the language "FLEX" is the problem.
I can't provide one URL because you need a user and password to use it because is an Online ERP.
Re: Problems with the actualization 31.4
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
- somdcomputerguy
- Lunatic
- Posts: 385
- Joined: 2014-02-23, 17:25
- Location: Greenbrier County, West Virginia
- Contact:
Re: Problems with the actualization 31.4
He didn't ask you, AlexBrainbond, what it was set to, he asked if setting it to true helped.AlexBrainbond wrote: ↑2022-11-24, 15:07No, the dom.keyboardevent.keypress.dispatch_non_printable_in_content is on "false"
-bruce /* somdcomputerguy.com */
'If you change the way you look at things, the things you look at change.'
'If you change the way you look at things, the things you look at change.'
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
Re: Problems with the actualization 31.4
oh yes yes, it works Thanks a lotHe didn't ask you, AlexBrainbond, what it was set to, he asked if setting it to true helped.
- somdcomputerguy
- Lunatic
- Posts: 385
- Joined: 2014-02-23, 17:25
- Location: Greenbrier County, West Virginia
- Contact:
Re: Problems with the actualization 31.4
Cool beansAlexBrainbond wrote: ↑2022-11-24, 18:00oh yes yes, it works Thanks a lotHe didn't ask you, AlexBrainbond, what it was set to, he asked if setting it to true helped.
-bruce /* somdcomputerguy.com */
'If you change the way you look at things, the things you look at change.'
'If you change the way you look at things, the things you look at change.'
- Memophenon
- Hobby Astronomer
- Posts: 15
- Joined: 2020-12-25, 13:15
Re: Problems with the actualization 31.4
This might solve my problem with TiddlyWiki not reacting anymore on Esc, Ctrl+Enter and Ctrl+Shift+Enter in order to leave a textarea field (and possibly store its modified content). How can I set dom.keyboardevent.keypress.dispatch_non_printable_in_content to true? By putting some JS code in some JS file in some directory?
- AlexBrainbond
- Newbie
- Posts: 6
- Joined: 2022-11-23, 11:27
Re: Problems with the actualization 31.4
Firstly, you must put in the searching bar this text: about:config
Then one alert page will apear but you will click on accept.
The third step you must to do is, put the directive on the search bar in to the page.
dom.keyboardevent.keypress.dispatch_non_printable_in_content
To end, you click 2 times to change "False" to "True"
Then one alert page will apear but you will click on accept.
The third step you must to do is, put the directive on the search bar in to the page.
dom.keyboardevent.keypress.dispatch_non_printable_in_content
To end, you click 2 times to change "False" to "True"
- Memophenon
- Hobby Astronomer
- Posts: 15
- Joined: 2020-12-25, 13:15
Re: Problems with the actualization 31.4
Now you've named it, it looks familiar. An old Mozilla feature, must have seen it in a previous life. And indeed, setting this property to true makes TiddlyWiki fully key-aware again.
Thanks for your help.
Thanks for your help.
Re: Problems with the actualization 31.4
AlexBrainbond wrote: ↑2022-11-29, 15:24dom.keyboardevent.keypress.dispatch_non_printable_in_content
To end, you click 2 times to change "False" to "True"
One some forums, ctrl-I, ctrl-B, etc, add tags for italic, bold, etc. Must have been since Pale Moon update, I noticed it stopped working.
I wondered if this worked for that case, and, for two vB forums I use: it does.
Thanks
Re: Problems with the actualization 31.4
Unfortunately it's either one or the other.
Some sites will break user input when keypress events are sent for non-printable keys (because they do checks on user input in real time and do not specifically handle non-printable keys, because none of the mainstream browsers do this anymore). Other sites apparently use keypress events to listen for non-printable key combinations like those formatting shortcuts and as a result break when they no longer receive these events.
It's not possible to do both at the same time.
For me it's more logical to send all keypresses to content when you have event handlers for it (i.e. our past behaviour, which is the same as having the pref flipped), but it's now the less compatible option.
Websites can solve this by listening on "keydown" instead of "keypress" if they want to catch non-printable keys.
Some sites will break user input when keypress events are sent for non-printable keys (because they do checks on user input in real time and do not specifically handle non-printable keys, because none of the mainstream browsers do this anymore). Other sites apparently use keypress events to listen for non-printable key combinations like those formatting shortcuts and as a result break when they no longer receive these events.
It's not possible to do both at the same time.
For me it's more logical to send all keypresses to content when you have event handlers for it (i.e. our past behaviour, which is the same as having the pref flipped), but it's now the less compatible option.
Websites can solve this by listening on "keydown" instead of "keypress" if they want to catch non-printable keys.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite