Restore status bar on PWAs

[Claudio Weiler]

Hi!

Chromium based browsers (tested on chrome and edge) do not show status bar on PWAs.

This is a terrible security issue! I use GMail as PWA, and I can't see real link targets, that should be shown on status bar as on non PWA version.

I think this was a product decision, as it first was removed but with a flag to re-enable it, but now this flag has gone.

Anyone knows about that?

There is any way to hack this to bring status bar back?

There is a filled bug on this?

Thanks!

[Jon Perryman]

If I understand you correctly, then it works fine on MS Edge Version 113.0.1774.57 (Official build) (64-bit). Using GMail, I select an email and hover the mouse over various extended attribute fields in the Email and I get the expected hyperlink display in the lower left. 

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[Claudio Weiler]

Hi Jon!

You described normal behavior, I'm interested on PWA behavior. PWA from Portable Web Applications.

Despite gmail isn't a formal PWA, you can create an "app" from it. But gmail was only a reference for the problem, this occur with any PWA created on Chrome or Edge, but for email sites configured as PWA this is a security issue IMHO.

Thanks!

[Claudio Weiler]

For reference...

This is the flag that doesn't exists anymore: https://beebom.com/remove-status-bar-from-google-chrome-pwas/

[Jon Perryman]

Most people don't understand PWA. PWA is Progressive (not Portable) and I find "PWA" too vague / misleading to be useful as a term. My definition would be web pages that can appear like a native app.

To some, it's a webpage that changes according to the device (e.g. the webserver or javascript may decide to reformat the display according to the devices like cell phones, tablets, PCs and more). Does it change with fullscreen, window/xwindow, mouse, touchscreen and more to appear with the same behavior as a native app on that platform? In other words, it's different depending upon too many things to list, least of which is personal interpretation.

.

You say I described normal behavior but ignore the definition of normal behavior when using Chromium. Behavior is different depending on many factors (e.g. android, apple, windows, x-windows, touchscreen, mouse and more). For PWA, most PWA behavior is defined by the web page with very few features specifically controlled by the browser..

You specifically complained that the status bar is missing and you don't see the real hiper-link. I seriously doubt that the status bar is useful in any way to most people because they don't think to do a long touch to see the hiper-link. While I've never used this feature, I just tried it on my android phone (similar to right mouse) and see the hyperlink at the top of the right mouse menu. Maybe this is the solution to your problem.

[Claudio Weiler]

Sorry. My English is poor and it can lead to misunderstandings...

>  PWA is Progressive (not Portable)  and I find "PWA" too vague / misleading to be useful as a term

Your are right, I was typing something thinking on the other. But, anyway, I don't think that we need to go deep into this...
The old flag was named "enable-desktop-pwas-remove-status-bar", so I think it's ok to call it PWA, even it isn't!
Let's call it "browser app", if it's better, as they can be accessed from "chrome://apps" or "edge://apps".

>  You say I described normal behavior but ignore the definition of normal behavior when using Chromium

Sorry. I tried to mean normal as a simple tab opened on browser.

> do a long touch to see the hiper-link ... I just tried it on my android phone (similar to right mouse) and see the hyperlink at the top of the right mouse menu
Long touch means portable devices, touch screens...
My fault, forget to add environment infos: I'm using a Windows device (desktop/laptop) without touch screen.
Long mouse left click do not shows link, I need to drag it. It's something as a work around, but the tooltip generated with dragging is much slower then hover tooltip (status bar) that can extend to (almost) all window width. Also, context menu on desktop is different from Android one's.

Thanks!

[Jon Perryman]

No need to apologize because your English is just fine.  

Like I said before, most people don't understand PWA. Open any MS Windows app (e.g. media player, wordpad, MS Word, calculator or ...) and prove that it's not PWA.  PWA's look and act like native applications. In a perfect world, you could not distinguish PWA and native apps. What tells you that GMAIL in Chrome is not PWA? The web address and tabs are displayed with various other browser options.You can hide these but that doesn't make it fully PWA compliant.

There is no such thing as browser apps. 

As for experimental flags, having PWA in the flag name only says this flag tests a possible feature planned for PWA. In this case, remove the status bar flag tested the web page as a native app that doesn't have a web browser status bar. If you are running Gmail as a native app as defined in chrome://apps, then you won't see the link displayed. Otherwise when you hover over the link, it will display at the lower left where the status bar used to be located.

I'm guessing you installed Gmail using chrome://apps (PWA) which removes most of the browser identifiable fields. If not, hover over the link and the link address should appear.

[Claudio Weiler]

I don't want to go into a deep discussion about PWA. What it is... What it is not... How it works... That's not the point of this thread. Also never intend to say that "browser apps" thing exists, that's why my phrase started with "let's call it...".

So, I will stick with PWA. Hope that this offtopic discussion ends. Please, don't get me wrong, it could be a good discussion, it's just not the point.

My issue is about a feature, natural on browsers , based or not on chromium, that was removed for a particular use case. The status bar display. Lets go into this...

Back in time, I used this type of use case (PWAs) since it's very beginning, when Chrome has first introduced this feature.

Some time later, something around 2021, Chrome added the flag "enable-desktop-pwas-remove-status-bar", and make it enabled by default, so, users that just want this behavior back could just turn this flag disabled. This feature looked good to users that wanted a more "native application" look and feel, with the end of tooltips pointing about resources downloads in progress or others "needless" information; but it come with the drawback of removing, also, tooltips showing real link URL target on mouse hover. Here we have a usage turn, no problem with that, as we have a fallback.

Now, this flag was removed on Chrome, and above mentioned behavior (no status bar) was turned default without fallback for users. Here we have a usage definition, without any way to customize this behavior, it is that way because it is that way. The above mentioned flag was simply removed, not turning into a browser option, or site option.

This lead to my concern about security issue, as when you define your mail app into PWA and lost the (again, expected) behavior of seen link targets with just a mouse hover in current times with lots of phishing emails. This was quick, practical, efficient and clean. You can think this is not a security issue, and I don't want to turn this into another offtopic discussion.

So, my original questions:

Anyone knows about that? (any link to discussions on this feature)

There is any way to hack this to bring status bar back?

There is a filled bug on this? (can't find nothing on web, apart a locked community question: https://support.google.com/chrome/thread/205058675/how-to-force-the-display-of-the-status-bar-in-pwas)

Thanks!

[K. Moon]

If there isn't an existing bug, it'd probably be more productive to file a new bug at crbug.com/new. I suspect this would be closed as working as intended, however. chrome://flags are intended to be temporary, so removing the status bar reflects the final launched state of the feature.

[Jon Perryman]

Since you couldn't find a bug report, there probably isn't one. Feel free to create one that includes all the features you need. It's very unlikely that they will resurrect the status bar but they might consider creating a solution for missing functionality. Displaying hiper-links on hover has been solved by displaying it at the bottom left except when running as a PWA. You will need extremely convincing argument for them to consider making the change.

chrome://flags are experimental flags that are eventually removed when the solution to a problem has been implemented. If developers wanted such an option, it would have been an option implemented in settings. You could add this to your bug report but I suspect they will decline this setting.

These changes have been vetted for security exposures. The hiper-link is not displayed while running as a PWA. All native applications (including PWA) are installed. PWA is no more a security risk than any other native app that does similar functionality. So yes there is a security exposure but it is the same exposure common to all apps. When native apps create a solution for this security exposure, then we expect PWA to follow suit and implement the same solution. 

If you open a bug report, please set your expectations very low. It's extremely unlikely this will be approved, especially considering this would be a very low priority that would take years to be implemented. This is not a simple change because it would need to go thru Mozilla standards approval. 

[Claudio Weiler]

Thanks K. Moon and Jon, I will think about filling an issue, but I really like to see the original conversation that lead to this design decision.

> These changes have been vetted for security exposures

Are you asserting this? That is exactly the type of discussion I like to be pointed!
obs. what you mean with "security exposure"?

> When native apps create a solution for this security exposure, then we expect PWA to follow suit and implement the same solution.

The problem is phishing, that is a mail issue. AFAIK both Thunderbird and Outlook (native) does show link targets, probably others native mail apps also, then we came into a crossroad if this is a Chromium or gmail issue, and probably they will point fingers each other.

obs. outlook.com shows an dedicated tooltip on link mouse hover.

> This is not a simple change because it would need to go thru Mozilla standards approval. 

From Chromium point of view, I would like nothing special. Just a option that could be changed, either globally or per site. The same option that existed on the removed flag.

[Jon Perryman]

PWA is not specific to Chromium based browsers. It is a standard that applies to other browsers that include Firefox.

As I said before, PWA would have been discussed as part of standards. Same as HTML standards are not browser where each statement must act the same across all browsers (e.g. <video>, <a>, <body>, ...).

I'm not familiar with how Mozilla develops standards. You would need to talk to the participants to find how they communicate and document their decisions.

As for security exposures, the standards group specifically discusses it with every standard. Right or wrong, their decision is final for the standard. If they forgot about Email phishing, then Mozilla standards group would need to address it first.

You say you aren't asking for something special but you ignore that you want Chromium to deviate from Mozilla standards. This is a very big deal and rarely will Chromium deviate from those standards. Right or wrong, the standards are to be followed or changed. You are asking for the standards to be changed and then Chromium to change according to the new standards..

[Claudio Weiler]

>  PWA is not specific to Chromium based browsers. It is a standard that applies to other browsers that include Firefox.

I agree, but Firefox has dropped native support for PWA. Now you need a extension. (https://connect.mozilla.org/t5/ideas/bring-back-pwa-progressive-web-apps/idi-p/35)

>  PWA would have been discussed as part of standards ...  but you ignore that you want Chromium to deviate from Mozilla standards
No! Never! There is standards, stick with standards, no more IE!
PWA is defined/described on MDN, but I hardly believe that hiding status bar is one of this standards. Can't find any entry about status bar behavior in PWA as standard, or even as best practices, on MDN.

[Jon Perryman]

>>  PWA is not specific to Chromium based browsers. It is a standard that applies to other browsers that include Firefox.
> I agree, but Firefox has dropped native support for PWA. Now you need a extension. (https://connect.mozilla.org/t5/ideas/bring-back-pwa-progressive-web-apps/idi-p/35)

Firefox didn't drop support for PWA. My guess is that they moved it to an extension because extensions can easily be deleted when they are no longer relevant. Do you actually believe Firefox will successfully maintain PWA for Windows, Linux, various Xwindows implementations, Android, Apple and every other platform where FireFox runs? Eventually, Chromium based browsers will remain current. MS Edge forces currency with Windows and Chrome forces currency on Android and ChromeOS. FireFox PWA will eventually become obsolete.

>>  PWA would have been discussed as part of standards ...  but you ignore that you want Chromium to deviate from Mozilla standards
>No! Never! There is standards, stick with standards, no more IE!
>PWA is defined/described on MDN, but I hardly believe that hiding status bar is

>one of this standards. Can't find any entry about status bar behavior in PWA as standard, or even as best practices, on MDN.

Clearly you are not familiar in dealing with standards organizations. ISO, ANSI, MDN, IEEE, DIN, NIST, CSCC, CSA just to name a few. It appears that PWA is under the MDN umbrella but I won't swear to it because I've never followed PWA standards. Standards are often too vague to say something is not documented. The Chromium status bar is so specific that it probably is not specifically mentioned. Instead, they probably use obscure wording that covers all platforms for many different things.

[Claudio Weiler]

> Firefox didn't drop support for PWA. My guess is that they moved it to an extension because extensions can easily be deleted when they are no longer relevant.

No guessing here. They dropped (it existed, them removed).

The extension: https://github.com/filips123/PWAsForFirefox

Quote from above extension readme: "Although Firefox supports many of Progressive Web App APIs, it does not support functionality to install them as a standalone system app with an app-like experience."

> Clearly you are not familiar in dealing with standards ... I've never followed PWA standards. Standards are often too vague to say something is not documented.

But you bring all this "standard" issue here. You mentioned Mozilla (MDN). You claimed that this is an standard defined behavior without linking to it.

I don't understand why I became the culprit here.

> Do you actually believe Firefox will successfully maintain PWA for Windows, Linux, various Xwindows implementations, Android, Apple and every other platform where FireFox runs?

Again, I bring nothing to this discussion, it's all you. You claimed this is a standard to be followed, not me. And the mentioned standard should be the behavior of status bar on PWA, not the PWA them self.

> The Chromium status bar is so specific that it probably is not specifically mentioned.

No, definitely, absolutely, no. Status bar is a common GUI resource, this resource is used by default in literally all desktop browsers.

This resource has changed behavior on browsers, from one bottom fixed "bar" (that is from where the name comes) that could be enabled/disabled, to the current behavior more like a tooltip shown only when necessary.

> they probably use obscure wording that covers all platforms for many different things

It's simply impossible that anyone will define behavior for the "status" information thing without naming it as a "resource to handle status information". Moreover that any browser always named this thing as "status bar".

[K. Moon]

This conversation seems increasingly detached from anything to do with Chromium. Perhaps a PWA-specific group would be a better forum? Regardless, I'd appreciate if this could be taken elsewhere, or refocused on the Chromium-specific aspects (but those are better taken up in a bug).

--

[anthon...@gmail.com]

If you file a bug I'll definitely star it.

I find seeing the link target for PWA-like websites when running in native PWA mode incredibly important from a security standpoint, if you are going to allow websites to impersonate being native applications.

It is better not to offer the feature if it can't be acknowledged that you're opening the user up to new pitfalls / vulnerabilities. I think it's worth filing a bug as this feature is dangerous to offer without acknowledging it requires different security considerations in comparison to a standard native app.

It really isn't the author which is going off-topic here. Please refrain from responding with here-say.

[Claudio Weiler]

Filled bug https://bugs.chromium.org/p/chromium/issues/detail?id=1450606