StrokesPlus.net
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
Lemon Juice  
#1 Posted : Sunday, February 17, 2019 2:37:49 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

I've been testing StokesPlus.net recently and I couldn't find an option that I think is pretty essential in mouse gestures. The problem is that when I use mouse gestures in web browsers sometimes after I start drawing a gesture I decide I want to cancel the action so I stop mouse movement and wait until the gesture has timed out - and then when I release the right mouse button the browser's context menu appears, which gets annoying with time. When I allow a gesture to time out this always means (at least for me) that I don't want anything to happen and I also don't want the application context menu to appear. Quite often I just want to perform a different gesture but for this I need to click in a neutral space somewhere to first get rid of the context menu.

Could we have an option so that the right click is not passed to the application after the gesture times out? That would be very handy. I don't know if an option like this existed in the old StrokesPlus application but certainly in the traditional mouse gestures extensions that existed in web browsers (like FireGestures, etc.) no context menu appeared when the user allowed the gesture to time out.

I can see StrokesPlus.net already behave like this when I draw a gesture that has not been recognized - no context menu appears, which is good. I'd like the same behaviour when a gesture disappears after a time out.

Edited by moderator Friday, June 7, 2019 7:14:08 PM(UTC)  | Reason: Not specified

Rob  
#2 Posted : Sunday, February 17, 2019 6:57:00 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
I will have a setting in the next update, which will be sometime today. Here's my pending change log update, since it has the notes about using this feature.
This won't be a visible setting in the user interface yet, I have a task to bring a bunch of these hidden settings into the Options screen, but I haven't got around to that just yet.

- Added setting sp_config.DisableRelayOnGestureTimeout (default false) which can be set to true if
you don't want S+.net to send the stroke button down event when you pause and let a gesture
timeout after the Cancel Delay. This will prevent certain actions like right-click dragging files
in explorer, waiting for the cancel timeout, then releasing the right button to reveal the
context menu options like Move Here, Copy Here, or Extract if it were a .zip file. You would
instead need to hold the ignore key down or call sp.DisableNext(); before performing this action.
Script to change and save this setting, make sure you have the Settings window closed when
executing this script:
sp_config.DisableRelayOnGestureTimeout = true;
sp_config.Save();


Rob  
#3 Posted : Sunday, February 17, 2019 7:01:12 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Also, it wasn't simply a matter of not sending the right click down upon timeout, but also absorbing the right click up event after S+.net has completely released the mouse/hook.
The other applications are reacting to the right click up, and at that point S+.net has stopped interfering with mouse events after the cancel delay was reached.

This will override that behavior and consume the next stroke / secondary stroke up event.
Lemon Juice  
#4 Posted : Sunday, February 17, 2019 1:34:27 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Thanks for your quick reply and action! I've just tested version 0.2.7.6 and this features works as expected. However, it is very buggy now to the point I can't use it:

The first thing I noticed is that when DisableRelayOnGestureTimeout is enabled then I can't right click on the S+ tray icon to bring up the context menu and go to the settings - nothing happens. But after I try this then all my applications become unresponsive to mouse clicks except the Windows task bar. I'm able to turn off S+ by left clicking the tray icon and then I can open the settings window and my applications become responsive again.

But then I decided to try simply using this feature without touching the S+ tray icon and see how it goes. I have S+ set to be active only in Firefox and Chrome applications so I used Firefox for a while and after the initial successful operation I noticed that suddenly right clicks stopped working in any of my opened applications. I tried the Vivaldi browser for these forums and there even left clicks weren't functional, although interestingly they performed visual effects like changing button styles but didn't actually press those buttons. Windows taskbar and tray became unresponsive to mouse clicks. I managed to open the Task Manager with Ctrl+Alt+Delete where left and mouse buttons worked but were reversed. I then ended the S+ process and all went back to normal.

There are some weird side effects when using this feature. When I turned DisableRelayOnGestureTimeout off all seems fine again.

Edited by user Sunday, February 17, 2019 1:38:54 PM(UTC)  | Reason: Not specified

Rob  
#5 Posted : Sunday, February 17, 2019 2:19:44 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Hmm okay, I'll have to dig into it further; I honestly hadn't tested it out a lot.

It was one of those things which adding in felt like it was going to be trouble, since it's trying to interfere with the mouse messages outside of the normal boundaries I've spent years trying to perfect for seamless operation :)
Rob  
#6 Posted : Sunday, February 17, 2019 2:53:50 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Ack, I never tested running in "only on defined apps" mode. That was an absolute shit show!

Okay, so at least the major aspect of that is fixed, along with a fix to some brain fart kind of condition check for that feature which would result in it always consuming the mouse up event under some circumstances.

Try 0.2.7.7 and let me know how it goes..
Lemon Juice  
#7 Posted : Sunday, February 17, 2019 5:38:22 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Thanks for the new version! I'll be able to test it tomorrow and I'll report how it goes.
Lemon Juice  
#8 Posted : Monday, February 18, 2019 2:57:31 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Yes, I use "only on defined apps". So far the new version works fine, that's great!

I can only see it changes right click events without mouse gestures - that is when I click and don't move the mouse. This can be seen at https://unixpapa.com/js/testmouse.html - normally, a right button mouse down event is detected immediately by the browser - and this is also how it works with built-in mouse gestures in Opera and Vivaldi. With S+ the mouse down even is not fired when the right down button is pressed but only when released - then all 3 mouse events are fired. I don't know if it is a problem or not. Theoretically, there can be a web site which uses right mouse down events for some functionality but I think that would be quite rare. I haven't yet come across a situation where that would be problematic - I'll leave it for you to decide if anything needs to be done about it.
Rob  
#9 Posted : Monday, February 18, 2019 10:20:51 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
There's really no way around that (at least not without impacting applications and users), since S+.net has to intercept the stroke button down event, then determine if you're drawing a gesture or not, otherwise someone who was starting a gesture would also be interacting with the application, such as right-click dragging. So when you right click down then release without moving the mouse beyond the minimum gesture distance, it sends the mouse down and up events upon release of the stroke button, to emulate the full right click.

You can right-click down and hold until the cancel delay has passed, that will send the mouse down event and when you release the button it will send the up event as normal.
Actually, I just realized I didn't account for that as it would still consume the up mouse event, I'll have to add some logic to check the distance to determine whether or not to consume the next mouse up. If you don't move the mouse far enough to trigger a gesture, it should send the down event and let your next mouse up even process as normal.

The only alternative would be to hold the ignore key to prevent S+.net from capturing the down event or use a different stroke button. Or call sp.DisableNext(); to ignore the next stroke button down event.

Built-in gestures have an extra advantage of being able to know what content the mouse is over inside the web page, which can help it to make different choices on the behavior. But it also may be that they simply don't intercept the right button down, not caring whether the user is trying to try a gesture or not.

Edited by user Monday, February 18, 2019 11:06:44 AM(UTC)  | Reason: Not specified

Lemon Juice  
#10 Posted : Monday, February 18, 2019 12:55:58 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

I think you are right - in the context of the being universal for all kinds of Windows applications passing through the mouse down event without yet knowing whether a gesture will be performed or not might not be a good idea. I just noticed this behaviour because I knew that traditionally mouse gestures in browsers worked differently - they allowed the mouse down event to be passed to the application immediately and if a gesture was started and cancelled then the mouse up was consumed, which resulted in a peculiar situation where a mouse down event was never followed by mouse up and in effect you could have a series of mouse down events without any up events. For browsers this seemed to pose no problems.

If the behaviour has to stay like this that's fine. I've noticed only some very minor cosmetic influences of that - sometimes a browser will style a link with an underline or a button with a certain decoration upon right mouse down, or the browser's address bar will change its style very subtly - those effects are lost now but they are too minor to worry about.

I'm being picky because I used to be a maintainer of Mouse Gestures Suite for Firefox at the time when that browser still allowed for powerful extensions so my point of view is more browser-specific :).
Rob  
#11 Posted : Monday, February 18, 2019 2:50:35 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Okay, try 0.2.7.8. I did test it on the mouse tester link you sent, and it seems to be sending events correctly. On right down hold until cancel delay, you see the down event show up after the cancel has happened, then the others when you release, as you'd expect.
Lemon Juice  
#12 Posted : Tuesday, February 19, 2019 12:23:01 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Indeed, it works better in the new version, thanks!
Lemon Juice  
#13 Posted : Monday, February 25, 2019 3:46:02 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Yesterday, I experienced a moment of buggy behaviour - when performing some simple gestures in Firefox like back and forward it looked like S+ didn't register my right button release and the gesture trail kept drawing continuously without me pressing any mouse buttons. With some clicks I was able to stop the gesture but then I realized I couldn't interact with any other application except Firefox. When clicking with the mouse outside Firefox or on the Windows taskbar nothing happened. I can't remember how I got out of this - probably with the use of Alt+Tab or some other keyboard shortcuts.

Unfortunately, I can't offer any more specifics as this happened only once and I don't know how to reproduce it. I have DisableRelayOnGestureTimeout turned on and only allowed apps are configured to work with S+. This was with version 0.2.7.8. Today I installed 0.2.8.2 but I didn't notice any bug fixes in the changelog so I suppose the same problem can potentially happen in 0.2.8.2, too.
Rob  
#14 Posted : Monday, February 25, 2019 10:14:39 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Bah, I knew that bug would come back after my previous fix for that broke rocker gestures behavior, so I rolled it back. It's a very difficult to nail down race condition, I'll have to look into it again. But as you said, the problem is it's very difficult to reproduce consistently, or sometimes at all. But from what I remember, it was clicking the left and right buttons at nearly the same time.

It's the only bug I'm aware of and it really pisses me off that the fix broke rocker gesture behavior! I was just waiting for it to show up again...
Lemon Juice  
#15 Posted : Tuesday, February 26, 2019 5:31:48 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

I don't know if it's important but I have rocker gestures disabled. I also doubt this was caused by clicking both buttons at the same time because when I actually tried it it takes some amount of effort with my mouse so it's not likely to happen by chance - but I may be wrong because I don't remember what I actually did. I'll report back if it happens again.
Rob  
#16 Posted : Tuesday, February 26, 2019 6:45:57 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Yeah, this was outside of rocker gestures, but whatever I did to fix it affected rocker gestures. I don't actually use rocker gestures, so I didn't notice how it broke the feature for a long time.

I'll have to go back in source control versions and see what I did back then, take a closer look in the context of also not breaking rockers.
Rob  
#17 Posted : Tuesday, February 26, 2019 1:30:28 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
You can also check this thread and download the trace version to run.

If you do, only check CoreCaptureEvents when it starts, will still be a lot of data in the log over time, but nowhere near if you check all!

You can also check MouseHookGeneralEvents, but I think CoreCaptureEvents should cover it.

Of course, there is a minimal impact on performance and resources, but if your machine isn't weak, you probably won't even notice. Then if it happens, grab the log and send it over, it helps immensely in following the sequence of events leading up to the failure.
Lemon Juice  
#18 Posted : Tuesday, February 26, 2019 3:36:08 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

I've installed the trace build and it works fine, I don't mind the additional writes to the disk, they seem to be minimal. But would it be possible to make the trace version more automatic? I mean, in my case I'd need to use the trace version all the time but it's a nuisance that on each S+ start I have to select what to log. Also, the trace version doesn't start on system logon, the normal version does (but I suppose I could easily change that myself). I'd like the trace build to not bother me at all after I configure it initially.

And I wonder - why is a separate version necessary for logging? Wouldn't it be much easier to incorporate logging into the normal version with configuration somewhere in the advanced options?
Rob  
#19 Posted : Tuesday, February 26, 2019 4:00:31 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Well, generally people won't need this, so I never made it user friendly.

And in terms of a different build, it adds CPU cycles to check if tracing is enabled. For most applications it's not a big deal, but when an app is hooking every keystroke and mouse event (including movement), it's just not worth the resource cost of those precious CPU cycles...especially for people with slower machines. I don't ever want S+.net to get in the way or be noticed, as much as possible.

But I'll look into improving the trace version some when I can.

Edited by user Tuesday, February 26, 2019 7:39:51 PM(UTC)  | Reason: Not specified

Rob  
#20 Posted : Thursday, February 28, 2019 6:00:14 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
In 0.2.8.3 I added some locks around the cancel timer, as comparing to the past it was just this one block of code that apparently caused the issue, and the only volatile calls happening in that section involved resetting or stopping the cancel timer.

So now there are locks around those functions internally, to prevent collisions, and some extra checks on the cancel timer object itself to ensure it's not referencing the timer when it's null. It could explain the rarity of the issue, as in you'd have to trigger the right sequence of events and at exactly the time the cancel timer was in the process of disposing or something.

Either way, these locks and checks are certainly good no matter what...and maybe it will also fix your issue. I tried feverishly to get the error to happen again (before making the changes above) and simply could not get it to happen.

Also, the 0.2.8.3 trace build will now remember your trace settings and not popup on start (once you've set them once and saved/exited). You can change them via the Set Trace Options tray menu item.

Edit: Actually might just want to hold off until 0.2.8.4, more stability and performance improvements, plus fixed the relay gesture on no match mouse positions as they were off due to a copy/paste fail.

Edited by user Thursday, February 28, 2019 11:52:14 AM(UTC)  | Reason: Not specified

Lemon Juice  
#21 Posted : Thursday, February 28, 2019 8:30:28 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Thanks for the new update, the locks seem to be a reasonable solution. The change is the trace version is also welcome. As you might guess, I haven't experienced the problem again, it really must be something very rare.

I'll wait for 0.2.8.4 then.
Rob  
#22 Posted : Friday, March 1, 2019 7:16:48 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Okay, made some pretty complicated/risky changes to many areas in the mouse hook logic, so I'm not publishing 0.2.8.4 publicly in the download post or via auto update.
Since you seem to be a very detail oriented and developer minded person, I trust you'll root out anything odd that you find.

I've posted the release to Discord as well, so it's not like I'm relying on you alone to be my tester :)

Edit: updated to 0.2.8.5, fixed a pretty annoying bug

https://www.strokesplus.net/download/0.2.8.5/installer
https://www.strokesplus.net/download/0.2.8.5/installertrace

https://www.strokesplus.net/download/0.2.8.5/portable
https://www.strokesplus.net/download/0.2.8.5/portabletrace

Edited by user Friday, March 1, 2019 11:09:33 AM(UTC)  | Reason: Edit: updated to 0.2.8.5, fixed a pretty annoying bug

Lemon Juice  
#23 Posted : Saturday, March 2, 2019 5:39:44 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Great! I've installed 0.2.8.5 and changed the startup shortcut to point to the trace version and all is working well. Now I will keep using S+ and if anything abnormal happens then hopefully I'll have the logs with useful information. I'm logging only CoreCaptureEvents since you say this is sufficient.

A minor enhancement in the trace version would be to preselect currently selected items in the Trace Options to be able to see what is currently enabled. Now all checkboxes appear unselected.
Rob  
#24 Posted : Saturday, March 2, 2019 8:32:09 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Yeah, it does remember the trace settings...it just was a bad index check so it wouldn't remember the first check...of course, the only one you're using!

Fixed in 0.2.8.6.
Lemon Juice  
#25 Posted : Saturday, March 2, 2019 12:42:56 PM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Indeed, it works fine now!

Are you planning to add UI for DisableRelayOnGestureTimeout option?
Rob  
#26 Posted : Saturday, March 2, 2019 9:51:50 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 208
United States

Thanks: 4 times
Was thanked: 39 time(s) in 32 post(s)
Yeah, I need go through and add many of the options to the UI I've added over time.
Lemon Juice  
#27 Posted : Wednesday, March 6, 2019 1:46:29 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Today I noticed a glitch with S+ when using SeaMonkey for viewing a PDF from a mail attachment. SeaMonkey is not added to the list of allowed application in S+ so theoretically it should not be affected by it but it look like it was. Also, just before this happened I didn't use any applications from the allowed list. Here is what I did:

1. I was browsing some mail messages in SeaMonkey mail.
2. In one message I opened a PDF attachment - it opens in SeaMonkey browser window where the PDF if loaded via the Adobe Reader plugin.
3. After viewing the PDF I wanted to use the same SeaMonkey window to load a web page so I clicked on the address bar but it didn't respond to my clicks (left clicks). It somewhat reacted by changing the font colour slightly when clicking but I couldn't place the cursor there to type anything. Neither left nor right clicks worked. Another weird effect was that the SeaMonkey top menu items were all greyed out just like they are when the window is in the background, however the menu reacted to mouse clicks and I was able to expand its items.
4. After a few attempts of trying to get out of this situation I disabled S+ with the tray icon and immediately SeaMonkey came back to normal and I was able to type in an address.

I don't know if it helps but here is the fragment from the log:

Code:

2019.03.06 09:20:22: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT DOWN
2019.03.06 09:20:22: MouseHook.cs::MouseProc(): CoreCaptureEvents: MouseEventSource: Mouse
2019.03.06 09:20:22: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT UP
2019.03.06 09:20:23: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT DOWN
2019.03.06 09:20:23: MouseHook.cs::MouseProc(): CoreCaptureEvents: MouseEventSource: Mouse
2019.03.06 09:20:23: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT UP
2019.03.06 09:21:31: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT DOWN
2019.03.06 09:21:31: MouseHook.cs::MouseProc(): CoreCaptureEvents: MouseEventSource: Mouse
2019.03.06 09:21:31: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT UP
2019.03.06 09:21:55: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT DOWN
2019.03.06 09:21:55: MouseHook.cs::MouseProc(): CoreCaptureEvents: MouseEventSource: Mouse
2019.03.06 09:21:55: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT UP
2019.03.06 09:23:08: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT DOWN
2019.03.06 09:23:08: MouseHook.cs::MouseProc(): CoreCaptureEvents: MouseEventSource: Mouse
2019.03.06 09:23:09: MouseHook.cs::IsStrokeButton(): CoreCaptureEvents: CURRENT STROKE BUTTON - Right - RIGHT UP


The problem started happening either at 09:21:31 or at 09:21:55 - I can't remember exactly which. I suppose the problem may have nothing to do with SeaMonkey and could happen with any other application. As usual, I have no idea how to reproduce it :)
Lemon Juice  
#28 Posted : Wednesday, March 6, 2019 2:24:42 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

I was able to reproduce the problem once again by opening a PDF attachment, however my SeaMonkey became buggy and it won't open any more PDFs (independently from S+) so I can't test it now. When I get it working again I'll post back. But from what I saw was an unusual window focus switching when a PDF is opened in this way: a new SeaMonkey window opens, then goes back into background and then gains focus again. Maybe this strange focus switching is what confuses S+?
Lemon Juice  
#29 Posted : Thursday, March 7, 2019 1:19:16 AM(UTC)
Lemon Juice

Rank: Member

Reputation:

Groups: Approved
Joined: 2/16/2019(UTC)
Posts: 18

Sorry about bothering you with the problem I described in my recent posts. It turns out it is not S+ bug but SeaMonkey's. I first thought it was S+ because disabling S+ fixed the behaviour but what actually fixes it is changing focus away from SeaMonkey. So please ignore this bug report. BTW, S+ is working fine so far, I haven't experienced anything wrong with my settings.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.