Avainsanana Firefox

URL of a federated WordPress post reopens the post in the app instead of a browser

14. marraskuuta 2023 klo 11.57
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Firefox, Mastodon, Samsung, WordPress

I’m using the ActivityPub plugin to enable following posts from my WordPress blog. The posts federate as excerpts with a URL pointing to the full post on my site.

Tapping on that URL in the Android app only causes it to reload the post (excerpt) inside the app, instead of opening the URL in either webview or a browser as I’d expect it to.

The (official) IOS app does open the URL a browser, as does Firefox on the desktop, which is why I suspect the Android app being at fault here.

I don’t know of a way to link my blog here it so that it opens in the app (which is a bit ironic), but here’s a deck link to the federated posts on mastodon.social. My personal Mastodon account is on mastodon.social.

Both my Android phone and Android tablet are affected, both are on Mastodon version 2.2.1. The phone is running Android 10 (with Samsung’s One UI 2.0), the tablet is on Android 11 (One UI 3.1).

Below is a screen recording from the Android phone exhibiting the issue: the first tap of the URL opens the federated note in single view, and subsequent taps then just reload that same view.

url_tap.mp4

Vastaa viestiin sen kontekstissa (Github)

JSON files attached to a card (with .json filename extension) are empty when downloaded

28. tammikuuta 2022 klo 14.01
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Apache, Brave, Firefox, Snap, Ubuntu, Wekan, Wikipedia

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

  • Did you test in newest Wekan?: 5.90
  • Did you configure root-url correctly so Wekan cards open correctly? yes
  • Operating System: Ubuntu 20.04
  • Deployment Method: snap
  • Http frontend if any: Apache
  • What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

  1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
  2. Open a card in Wekan.
  3. Select + from the Attachments section.
  4. Select ”Computer” from the popup.
  5. Select example.json.
  6. With the JSON file now attached to the card, select to ”Download” it.
  7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

  • Deleting the attachment seems to work.
  • The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Vastaa viestiin sen kontekstissa (Github)

Opening the hamburger menu works in 95.0a1; closing still partly broken

22. lokakuuta 2021 klo 19.57
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox

I tested 95.0a1 (Nightly), and opening the hamburger menu (using the steps I outlined above) works now.

Closing it is still partly broken though, as clicking on the menu button doesn’t close the menu; I think that is bug 1694514.

For a workaround, clicking outside the menu (and the menu button) does close the menu.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I tested the 94.0a1 nightly now, and the issue is still present

20. syyskuuta 2021 klo 21.50
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox

Also, I tested the 94.0a1 nightly now, and the issue is still present.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I ran mozregression and got the first bad revision

19. syyskuuta 2021 klo 20.00
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Wayland

I ran mozregression like this (twice, to be sure):

MOZ_ENABLE_WAYLAND=1 mozregression --profile /home/jani/.mozilla/firefox/fyaus28k.LP1940417 --bad 91 --good 89 --profile-persistence clone-first

Here’s the result (it was the same for both bisects):

5:25.73 INFO: No more integration revisions, bisection finished.
5:25.73 INFO: Last good revision: 9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8
5:25.73 INFO: First bad revision: 7b82d177a6b979036f180329be6b029d690d9e0c
5:25.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8&tochange=7b82d177a6b979036f180329be6b029d690d9e0c

According to that log, this changeset was introduced to address #1661516.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

The trigger for this is MOZ_ENABLE_WAYLAND=1 and layout.css.devPixelsPerPx=1.2

11. syyskuuta 2021 klo 13.08
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox

I can’t speak for Jeroen, but I played around with the upstream builds (both 92 and 91) and my faulty profile a bit and managed to isolate the trigger combination for this: MOZ_ENABLE_WAYLAND=1 and setting layout.css.devPixelsPerPx to my preferred value of 1.2; either resetting layout.css.devPixelsPerPx to its default (-1.0), or running Firefox without MOZ_ENABLE_WAYLAND=1 will make the toolbar items work again. Here’s the graphics portion of my about:support.

So my steps to reproduce this are:

  1. start Firefox with MOZ_ENABLE_WAYLAND=1
  2. set layout.css.devPixelsPerPx to 1.2
  3. click on the hamburger menu button

What I expect to happen:
For the hamburger menu content to show.

What happens instead:
The hamburger menu content flickers or doesn’t show at all.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Here’s the updated steps to reproduce

28. huhtikuuta 2021 klo 14.05
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Launchpad, Twitch

Steps to reproduce

  1. Open about:config
  2. Search for autoplay in the settings
  3. Set media.autoplay.default to 1 (”Block Audio”, which is the default)
  4. Set media.autoplay.blocking_policy to 2
  5. Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
  6. Try to unmute the video (either by clicking Twitch player’s speaker control button, or by dragging the accompanying volume slider)

What I expect to happen

For the audio to be unmuted.

What happens instead

The audio remains muted, and the volume control/indicator remains in the muted position.


I’m unmotivated to report this to Twitch, as I’m unsure about the precise meaning of media.autoplay.blocking_policy, and I currently don’t use the non-working value for it myself. Feel free to downprioritize this as you see fit, unless the original reporter is still affected. Here’s my downstream report over at Launchpad though, just for reference. (I’ll update it too.)

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Does not appear to have been fixed by Firefox 88

26. huhtikuuta 2021 klo 18.45
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitch

Hi Alex!

It does not appear to have been fully fixed by Firefox 88 for me at least, although the conditions have changed slightly, and the remaining broken behavior is now slightly different too.

First, to update my note above: media.autoplay.enabled.user-gestures-needed has been superseded by media.autoplay.blocking_policy, and setting the latter to 2 is now required to trigger the issue (as it manifests presently); with the setting at either 0 or 1 I haven’t been able to reproduce any variation of the issue.

Now, the video doesn’t get paused anymore, but the unmuting also does not work: clicking the muted indicator just always resets it back to muted, instead of actually unmuting.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I haven’t seen this since Ubuntu-distributed Firefox was updated to 84

20. joulukuuta 2020 klo 12.12
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

For me this seems to have resolved itself since Ubuntu-distributed Firefox was updated to 84, though for all I know, it may have just coincided with some change implemented at Twitter’s end.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Twitter tabs don’t load in Firefox when set as home

13. joulukuuta 2020 klo 16.37
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Twitter, Ubuntu

I’m affected by this too, in Ubuntu 20.04 with Firefox 83.0+build2-0ubuntu0.20.04.1.

Tested nightly (85.0a1.en-US.linux-x86_64) with a clean profile, and the issue remains.

Steps to reproduce

  1. Start nightly with ./firefox -no-remote -profilemanager
  2. Create a new profile, select it and click Start Nightly
  3. Open these three tabs (replacing the first-run tabs currently open):
  1. Open preferences, set Home to Custom URLs…, select ”Use current pages”
  2. Close the window
  3. Start nightly again with ./firefox -no-remote -profilemanager, select the previously created profile

What happens

None of the three tabs load any content. The firefox process also doesn’t end after closing this window with the non-working tabs, I have to Ctrl-C out of it.

Further info

Upon subsequent starts, Nightly does appear to correctly load the tabs, whereas for my main Twitter profile and FF 83.0 no amount of restarts seems to help; instead I have to open another tab and open m.twitter.com in it, then click on the home button to have the home tabs load (and close the first, still stuck set of home tabs).

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Vanhempia »