Closed Bug 1887056 Opened 1 year ago Closed 9 months ago

The *minimum* size of the window that the `share()` API invokes on KDE Plasma 6 is too small for its content.

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 123
x86_64
Linux
defect

Tracking

()

RESOLVED MOVED

People

(Reporter: zn7esutb, Unassigned)

Details

Attachments

(6 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

  1. I installed https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/MozillaFirefox-123.0.1-1.1.x86_64.rpm.

  2. I invoked the browser-native share menu at https://www.16personalities.com/profile#:~:text=View%20past%20results-,share%20your%20profile,-Let%20someone%20else, which caused

    to appear.

  3. I resized that child window using https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/kwin6-6.0.2-1.1.x86_64.rpm's standard resize handles.

Actual results:

became the minimum size I was able to resize it to.

Expected results:

Its minimum size should remain determined by its content, rather than become an apparently arbitrary value, merely upon resize.

https://bugzilla.mozilla.org/show_bug.cgi?id=1887056#c0

My Markdown image embeds

![]()

don't appear to have rendered. They should at least display the textual fallback. That's another bug for https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm%7Cbugzilla.mozilla.org, then. Apologies — I'll upload both to https://bugzilla.mozilla.org/attachment.cgi?bugid=1887056&action=enter too, but they're also available at https://imgur.com/a/CS7mXji.

Attached image How it is before being resized. (obsolete) —

This is how it should be.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Priority: -- → P3

Comment on attachment 9392784 [details]
How it is before being resized.

I accidentally uploaded the same damn image twice.

Attachment #9392784 - Attachment is obsolete: true

Anyway, I'll upload some screenshots to demonstrate that the issue is now inverted - the minimum size is insufficient for its content.

Attachment #9392782 - Attachment description: Depiction of the problem. → Minimum size after resize in firefox-123.x86_64

Is that a recent regression? Can you use mozregression to find the broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks!

Flags: needinfo?(zn7esutb)

#c7

:stransky, it's back to how it was, now.

Considering the difference in populated content, my estimate is that the minimum size is hard-coded, which manifests as too large when the content is ⪅ approximately 5 items, and too small when ⪆ approximately 6 items.

I've attached a screenshot to demonstrate, and shall attach another. Then, I'll rename all of them, for consistency when comparing them. The colour scheme shouldn't matter.

Flags: needinfo?(zn7esutb)
Attachment #9464034 - Attachment description: Default size in firefox-134.0.2-1.fc41.x86_64 → Default size in `firefox-134.0.2-1.fc41.x86_64`.
Attachment #9464033 - Attachment description: Minimum size in firefox-134.0.2-1.fc41.x86_64 → Minimum size (after resize) in `firefox-134.0.2-1.fc41.x86_64`.
Attachment #9392782 - Attachment description: Minimum size after resize in firefox-123.x86_64 → Minimum size (after resize) in `firefox-123.x86_64`.

It's back to how it was, now.

Apologies – It's not. I was confused by the really old, first image of firefox-123.x86_64.

Considering the difference in populated content, my estimate is that the minimum size is hard-coded, which manifests as too large when the content is ⪅ approximately 5 items, and too small when ⪆ approximately 6 items.

I've basically confirmed my estimation by using the gold-standard ECMAScript implementation of the share() API at developer.mozilla.org/en-US/docs/Web/API/Navigator/share#examples via its "Play" option. As before:

  1. It produced what appeared to be a QtWidgets (or, at least, GTK3) context menu (so not the standard Firefox one) consisting of 6 items.
  2. When resized to its minimum, it's slightly too short, but significantly too thin. The behaviour is identical, summarily.

I believe that this may be a platform issue.

OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Summary: Resizing native share window sets wrong minimum size. → The *minimum* size of the window that the `share()` API invokes on KDE Plasma 6 is too small for its content.

I'm confused. So dom.webshare.enabled is false for me. If I flip that, I get a NotSupportedError instead. So that seems something that's not in the tree?

Flags: needinfo?(zn7esutb)

So "dom.webshare.enabled" is false for me. If I flip that, I get a NotSupportedError instead.

:emilio, likewise, somewhat:

  1. "dom.webshare.enabled" was false for me by default, too.

  2. Setting to true produces the undermentioned, verbatim:

    Error: NotAllowedError: Navigator.share: Document's Permissions Policy does not allow calling share() from this context.

    ...which evidently differs from yours, but the consequence is identical.

So that seems something that's not in the tree?

However, you shouldn't need that preference to reproduce this. Would a screencast to verify this be useful?

Flags: needinfo?(zn7esutb)

Sure, I don't know how to spawn the dialog you're seeing with Mozilla binaries...

#c13

Sure, I don't know how to spawn the dialog you're seeing with Mozilla binaries.

:emilio, I've attached it, but it's also available at better quality at youtu.be/fbo-L2Vqwp4. The first accidental automatic resize reversion depicted is a consequence of bugs.kde.org/show_bug.cgi?id=496876#c0, so ignore it.

Regarding your previous comment, am I correct that you learnt of that preference from gist.github.com/marcoscaceres/ffcdde82394b27a7cb7cd22be755a0c1? If not, where? Additionally, if you're unable to reproduce it in whatever binary you're using, perhaps try installing Fedora 41's KDE Spin in a VM.

Apologies for the wait – I've a slow InterNet connection...

#c10

I believe that this may be a platform issue.

Per discuss.kde.org/t/31765/4, this is KDE's problem. Consequently, I have reported this to bugs.kde.org/show_bug.cgi?id=501812#c0, instead.

Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: