Change the styling and behavior of hyperlinks

[abey79]

What

This PR changes the styling and behaviour of hyperlinks, of which there are currently two three:

1. The "Help" item in the menu. I changed it to behave just like a normal menu item does. On click, it'll always open a new tab, which is a departure from the current behaviour where opening in a new tab required a modifier (alt, etc.) or a middle-click. I believe this behaviour respects better the "rule of least astonishment" in the case of WASM builds. (For native build, it doesn't change anything.)
2. The link in the "About" panel. For this I just changed the style to use "normal" colour (ie. white), but keep the link behaviour (underline on hover). The link in the about panel is removed entirely as it is redundant with the top-bar gigantilink.
3. The gigantilink, which has its own image-based styling (which will soon be revisited). This PR changes its behaviour to open link in new tab.

Warning

The forced "new tab" triggered the popup blocker on my computer, so that maybe a motivation to stick with opening help in the same tab by default. Opinions? Opening in new tab used to—and will continue to—trigger popup blocker. This is due to the browser not being aware that some user interaction occurred within the wasm executable.

Fixes #2733

Before:

After (mouse hovering on link, thus the underline):

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview

[martenbjork]

Nice! This link has an underline while the "help" link doesn't. I think we can skip the underline for this link. I also think we can drop the tooltip since it isn't adding any value.

[abey79]

@martenbjork Actually, do we want to keep that hyperlink at all? It's redundant with the massive "rerun.io" that's already on the title bar.

[martenbjork]

I'd be down to drop it! But the gigantic link present everywhere, even in the desktop app? If so, let's drop it!

[abey79]

Yep it is. Unless we want to drop that big link, then yeah, let's drop the link in the about.

[martenbjork]

All right good call! And I'll work on improving the design of gigantilink.

[abey79]

How do you feel about the "Help" behaviour. Currently it always open in new tab, which is inconsistent with the gigantilink, which needs a modifier and/or middle click for that. Because of the popup blocker thing, I'm leaning towards defaulting to same tab as well or "Help".

[martenbjork]

We should definitely make them consistent.

• Same window

  • 👍 Works just like any link on the web.
  • 👎 Is there a risk of loosing work if you suddenly navigate away from the app?

• New tab

  • 👍 Works like any link on the web with target="blank"
  • 👍 Allows you to keep working on "the thing you need help with"
  • 👍 Won't disturb your workflow

I'd lean towards a new tab. Are you concerned about pop-up blockers? AFAIK, target="blank" in HTML is never blocked, but maybe it's different when triggered from WASM?

[abey79]

👎 Is there a risk of loosing work if you suddenly navigate away from the app?

Yes. Open https://demo.rerun.io, delete a space view (eg), click on the gigantilink, back, space view is there again. (Though maybe not always? Depends on the browser caching implementation?)

Are you concerned about pop-up blockers?

I got that on safari! I had to click and allow.

AFAIK, target="blank" in HTML is never blocked, but maybe it's different when triggered from WASM?

Need to figure out how/if we can do that from rust/wasm.

[abey79]

Apparently it's using _blank for new tabs. I'm unsure why the popup blocker triggered. Regardless, I still prefer default to tab because of the lossy behaviour otherwise. Especially with the "Help" menu item where the user might expect help to show up inside the app.

[martenbjork]

I'm unsure why the popup blocker triggered

The HTML standard says _blank opens a "new window", maybe that's why. Most browsers today interpret this as "new tab", but I think it's up to the browser vendor.

Regardless, I still prefer default to tab because of the lossy behaviour otherwise.

Agreed! 🚀

[abey79]

This might explain safari's behaviour: https://stackoverflow.com/a/2587692/229511

Basically Safari isn't aware of user interactions inside the wasm executable.

[martenbjork]

This might explain safari's behaviour

Ah, that makes perfect sense!

[abey79]

Note that the previous behaviour of opening in new tab with modifier/middle-click was also popup-blocked! One more reason to default to new tab.

[martenbjork]

Jikes, Safari is really nervous about those WASM links, eh? 😀

[Wumpf]

code lgtm. didn't get to see the latest gigalink version on demo.io yet, but what could possibly go wrong

[abey79]

Jikes, Safari is really nervous about those WASM links, eh? 😀

Indeed. Both Firefox and Chrome seem better behaved by default. Leniency or better ability to detect user interaction? Who knows...