Prevent context menu options for tabs in focus mode

[MachineMitch21]

Fixes #2643

Open Questions/Comments

There is an open question as to whether or not "Go Forward" and "Go Back" should be options in the context menu while in focus mode, too. I was thinking about that while making these changes, and it seems that it could go either way. It's a lot "harder" to navigate that way while in focus mode, so maybe that's fine?

Changes

• js/browserUI.js
  Prevent addTab from doing anything if focus mode is enabled.

• js/webviewMenu.js
  When building the webviewMenu the options to open in new tab, open in new private tab, view image, open image in new tab, or open image in new private tab will not get built into the resulting menu when focus mode is enabled.

[MachineMitch21]

browserUI appears to be reluctantly the most viable candidate for this central focusMode check. Middle click behavior spawns events that may take some deeper main process finessing, and I'm not sure if it would be worth it to mess with middle click behavior as a whole.

webviews and viewManager simply react to the browserUI initiating the addTab process, so this seems the most viable option as a "last ditch effort" to prevent addTab() in focusMode

[PalmerAL]

I agree that browserUI is the right place for this, since it's the only central place that every addTab call goes through.

I don't immediately know what to do regarding go back/go forward. I think I agree with you that it's fine to leave them included. Actually, I wonder if we should start displaying the back/forward buttons in focus mode also, but I'm not sure about that either.

I don't think there's any reason to hide "view image". I know that you wrote:

Users can get stuck viewing an image while in focus mode because they can't go back or exit the tab

But the same thing is true of clicking any link on the page, and we still allow that. Since this opens in the same tab I think of it as being equivalent.

[MachineMitch21]

Some interesting things I just found after getting back to this (after all the changes already made):

• Right clicking a tab while in focus mode still allows a user to move a tab to a new window
• When a user clicks a link on a page, it appears to be queued up in a tab list but not shown
  • Once the user then goes to click "move tab to new window" new tabs are added to the current window for each time a link was clicked on the current page AND a new window is created.
• And, when a user clicks "duplicate tab" then they click "move tab to new window" similar behavior as above occurs.

But the same thing is true of clicking any link on the page, and we still allow that. Since this opens in the same tab I think of it as being equivalent.

Hmm, if we were to commit the kinds of changes made in this PR, then it would slightly change this behavior. Focus mode would become a tad bit more strict and disallow the clicking of links in almost any instance (except for the above right click tab context menu options).

---

I hardly ever use focus mode in any browsers (actually, I don't think I've ever really used focus mode personally in any browsers), so my opinion of how it ought to operate might not be the greatest. Perhaps if a user wants to focus on a specific set of tabs already existing in their current navigation history, then what you're describing could be good.

---

As for the above mentioned issues with the tab right click context menu, I think I'll need to look into why exactly that's happening, then prevent it. I suspect that something is directly interacting with tabs.add, then calling addTab with the newly created tab id, BUT the actual rendering event of the new tab(s) isn't actually running until the new window creation happens and the main process triggers an ipc event that would do that. But I don't currently know what that would be.

[MachineMitch21]

I pushed up another commit that would prevent the queueing up of duplicate tabs until an aggregated set of createView events would be fired off when the user would click "open tab in new window"

The reason that was happening:

• browserUI.js changes prevented the actual creation of the tab, and thus also blocked the createView event from happening. So this caused the queueing up of new tabs via the tab context menu options.

Let me know what you prefer for the view image behavior. I personally think it's valid to prevent viewing images in new or same tab, if the user is unable to navigate away from the image once they've gotten there. It seems like it would put them into a bind, causing them to need to exit focus mode, then re-enable focus mode should they want to continue working in focus mode after navigating away from the image. Maybe that's not a bad thing, though. It just offers a bit of an odd conundrum since, if they can't navigate away, why should they be able to navigate to that point?

But if we were to allow move forward and go back in focus mode, then maybe this problem solves itself.

[MachineMitch21]

NOTE -- I went back through and did another test while in and out of focusMode. Resetting tabMenu in a different scope when focus mode was disabled made things angry. The tab menu was not rendering at all after my previous commit. It will now render with all options when focus mode is disabled, and it will render without "duplicate tab" and "open tab in new window" options while in focus mode.

[PalmerAL]

I pushed up another commit that would prevent the queueing up of duplicate tabs until an aggregated set of createView events would be fired off when the user would click "open tab in new window"

This seems to work for me, so I'm probably misunderstanding what the bug is. Can you make a short screen recording of the original issue?

Right clicking a tab while in focus mode still allows a user to move a tab to a new window

To me, this seems fine to allow - you're still looking at the same set of tabs, just in a new window configuration - eg if you decide you want to look at two tabs side-by-side. Focus mode really just exists to prevent distractions from opening new tabs.

However, it looks like after clicking "move tab to new window", the newly-opened window is not in focus mode; that is a bug that should be fixed (not necessarily here, unless you want to).

But if we were to allow move forward and go back in focus mode, then maybe this problem solves itself.

That's what I'm leaning towards. What do you think about it?

I think disabling all link clicks is impractical - I imagine you'd very quickly reach a situation where you need to click on something, and then you'd be forced to exit focus mode to do it. But as you mention, the way things are also creates some opportunities to get stuck. To me, it seems like allowing back/forwards would still match the intent of focus mode while solving this issue.