> How is this different from any other request to a website?
It's not. Which is the point. The share menu is supposed to just pass a URL from Safari to another app. It's a glorified copy and paste, not a page load.
> The share menu is supposed to just pass a URL from Safari to another app. It's a glorified copy and paste, not a page load.
Says who?
It's used to show the icon and page title. That seems useful.
I think your expectations are unrealistic. If it's somehow extremely critical you don't actually make any requests to this URL then you're already playing with fire here, as it's not too hard to accidentally click the wrong mouse button or whatnot.
> It's used to show the icon and page title. That seems useful.
How so? Please explain how the iana.org icon in the blog post screenshot is useful.
Moreover, as the Addendum explains, that information is not even passed along to the other app when the URL is shared. It only appears in the share menu but ironically doesn't get shared.
Yes, I read that; in the screenshot it shows the icon and title of the page you're about to share. That seems useful. You may personally not find that useful, but clearly people do.
> You may personally not find that useful, but clearly people do.
How is that clear? I understand that someone inside Apple decided this was a good idea, perhaps for aesthetic reasons, but that's not the same as being clearly useful to people.
I agree that GP is kind of misusing the word "useful", but I do think you're missing the point. People like using aesthetically-pleasing software; improving aesthetics adds "value" if perhaps not "usefulness".
First off, the share menu is an OS feature, not part of Safari. So this isn't Safari doing anything other than sending the URL to the share sheet, and the person has selected to share through a medium that allows previews.
When you send a url through the share menu to a share extension that supports previews the share sheet needs to include: the title of page and a preview, and that's what's happening. Scraping the content from the currently open page would require the share sheet to be able to read state from the app triggering the send, or if the API allowed that app (safari in this case) to just include everything the app would need to do to a fresh request from an private context to give the best approximation of what the recipient would get, and so the "re-load of everything" would still be required.
Finally, even if the app did want to use the existing page state, people seem to like the open graph meta tags that provide summary text or images which may not have been loaded, so they'd have to be requested instead.
Go to your message client, type in a url (say a tweet on twitter) and send it, most clients these days include a preview, and that's the load you're seeing.
It's not. Which is the point. The share menu is supposed to just pass a URL from Safari to another app. It's a glorified copy and paste, not a page load.