Yep, retrying does work
Yep, retrying does work.
I’ve now reported this to Mozilla and linked to it. Thanks, Olivier!
Yep, retrying does work.
I’ve now reported this to Mozilla and linked to it. Thanks, Olivier!
(My) original report on Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1820514
Any page under https://forums.tomshardware.com/ seems to trigger this, but I have yet to come across other sites that do. Pages can even be saved from the main Tom’s Hardware domain (https://www.tomshardware.com/) without issues.
A workaround discovered by Olivier Tilloy: clicking retry in the download manager completes the save.
Steps to reproduce:
Actual results:
There’s no copy of the page in the target directory. Going to about:downloads reveals that the download has failed, without further details.
Expected results:
For the directory to contain a downloaded copy of the page.
Tested all combinations of both (Ctrl-s/context menu in safe mode and normal mode), all with the same results. Could this be locale-dependent? The UI is in English in safe mode though, so I’m guessing safe mode should be locale-independent, as I’m on fi_FI.UTF-8 otherwise.
And just to clarify: my testing of Bionic was on real hardware as well, and I ran these latest tests on Cosmic on another computer (real hardware).
== Steps to reproduce ==
1. Open https://forums.tomshardware.com/threads/what-is-the-actually-difference-between-udimm-and-dimm.1575984/
2. Right-click and select ’Save page as’. Point the dialog to your directory of choice.
== What I expect to happen ==
For the directory to contain a downloaded copy of the page.
== What happens ==
There’s no copy of the page in the target directory. Going to about:downloads reveals that the download has failed, without further details.
== Other info ==
I’m reporting this from up-to-date Disco, albeit with a 4.* kernel (as gdm currently fails to start in my VirtualBox VM with 5.*) but it’s equally reproducible in Bionic.
Any page under https://forums.tomshardware.com/ seems to trigger this, but I have yet to come across other sites that do. Pages can even be saved from the main Tom’s Hardware domain (https://www.tomshardware.com/) without issues.
Under some circumstances, content from one Firefox window hidden behind another leaks onto the top one. Reproducible in both Bionic (with Intel graphics) and Disco (in a VirtualBox VM), reporting this from Disco.
== Steps to reproduce ==
1. Open one Firefox window, drag it to the right side of screen to fill the right half, and navigate to https://www.twitch.tv/rifftrax
2. Open another Firefox window, maximize it on top of the first one, and use this topmost window to open https://www.youtube.com/watch?v=P5dxd-ocaE8 and expand the Youtube view to ’theatre’ mode
== What happens ==
White parts of content in Firefox window #1 cast a spectral shadow on the black parts of content in Firefox window #2. It’s quite subtle, but luckily can be caught in screenshots: see attachments below. Pausing the Youtube video seems to make the effect to go away (the transparency disappears).
== What I’d expect to happen ==
For the topmost window to be completely opaque, i.e. not to see anything from behind the topmost window whether the video is playing or not.
== Other info ==
Though I don’t think this is tied the two sites I’ve used as an example, they’re the first and only ones I’ve happened to encounter this with. I’ve yet to find other reports about this, apart from one /r/Fedora thread mentioning something similar: https://www.reddit.com/r/Fedora/comments/7m9m4h/youtube_videos_are_transparent_kind_of_in_firefox/
Untouched screenshot of top window revealing content from another window below
Server Setup Information:
Problem description:
Since (at least) a few days back, my web console (in both Firefox and Chrome) is logging this error whenever I open a card. The same error is also logged for opening a board. Additionally, in the more compact view (when the browser window is small, as in the gif I’m attaching), expanding a list causes the same error, as does closing a card.
This doesn’t seem to affect any functionality AFAICT (although I did notice this while investigating why vertical scrolling within a card is suddenly very slow, but that is probably unrelated and possibly local).
The attached animation is from a fresh install with just the user account and one test card created.
Steps to reproduce:
What happens:
”Exception from Tracker afterFlush function”, ”ReferenceError: Ps is not defined”. Web console log attached.
If using Snap, output from sudo snap logs wekan.wekan
(Nothing during the error event)
I’ve hit an issue, which I believe I’ve now isolated to have come from upgrading fontconfig (and related packages) from 2.12.6-0ubuntu2 to 2.12.6-0ubuntu2.3 from -proposed: if I start Firefox and afterwards start Gparted or Synaptic, Firefox starts eating up all of my CPU. Eventually all letters in the Gparted/Synaptic UI turn into boxes.
Syslog typically then says something like below:
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: failed to create cairo scaled font, expect ugly output. the offending font is ’DejaVu Sans 11′
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: font_face status is: out of memory
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: scaled_font status is: out of memory
Dec 4 13:41:50 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:50.995: shaping failure, expect ugly output. shape-engine=’PangoFcShapeEngine’, font=’DejaVu Sans 11′, text=’Päivitä’
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: failed to create cairo scaled font, expect ugly output. the offending font is ’DejaVu Sans 11’
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: font_face status is: out of memory
Dec 4 13:41:51 saegusa synaptic.desktop[30027]: (synaptic:30028): Pango-WARNING **: 13:41:51.007: scaled_font status is: out of memory
The computer has 32 GB of memory and there’s plenty still usable when this occurs, so the OOM seems incorrect to me.
To be sure, I rolled back entirely from -proposed (which caused the issue to go away), then re-enabled -proposed and upgraded just fontconfig, and the issue reappeared.
So I did a little more digging, and found that this actually first cropped up in Ubuntu 17.10.
I then ran mozregression (back on 18.04, my main desktop) and here’s what it found:
7:12.48 INFO: Last good revision: 64bab5cbb9b63808d04babfbcfba3175fd99f69d (2017-10-25)
7:12.48 INFO: First bad revision: aa958b29c149a67fce772f8473e9586e71fbdb46 (2017-10-26)
7:12.48 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=64bab5cbb9b63808d04babfbcfba3175fd99f69d&tochange=aa958b29c149a67fce772f8473e9586e71fbdb46
After that ”There are no build artifacts on inbound for these changesets (they are probably too old).”
As this was my first time ever using mozregression, I have no idea how useful that was, but if there’s some way I can narrow this down further, I’d be happy to.
Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.