[desktop] Bugs logged by Desktop Release QA in the last 8 days
Hello, Here's the list of new issues found and filed by the Desktop Release QA team last two weeks. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/yc4cgtax Bugs logged by Desktop Release QA in the last 8 days Firefox: Installer NEW - https://bugzil.la/1472937 - [MAC] DMG quantum background image not reset if bugged installer is mounted Firefox: Session Restore NEW - https://bugzil.la/1473055 - Youtube scroll position is not correctly restored from a previous session Core: Graphics: Text NEW - https://bugzil.la/1473041 - [Ubuntu] Glitchy text shadow in the beta and release Firefox firstrun page Core: Layout NEW - https://bugzil.la/1473820 - about:addons section holding the list is selected on clicks This is available as a Bugzilla bug list as well: https://tinyurl.com/ycxqu69w Regards, Bogdan (:bogdan_maris) Desktop Release QA ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Join the ASan Nightly Project!
Hey Christian, This is great! I'm super excited. ASAN helps in another way, besides just giving us much better UAF diagnostics: it catches issues besides crashes! It's very common for small buffer overflows to not corrupt things quite enough to crash. Two small questions: 1) Is there a metabug or anything to follow along with, for folks who interested to track the success of this? 2) My understanding is that we don't have macOS-ASAN-nightly (which, as a macOS user, I'm interested in) because we don't have enough macOS CI capacity to add ASAN builds to all pushes (as we do with Linux and Windows ASAN), is that right? Alex On Mon, Jul 9, 2018 at 11:43 AM Christian Holler wrote: > tl;dr If you run Linux with at least 16 GB of RAM and you would like to > help making Firefox even more secure and stable, please consider joining > the ASan Nightly Project by using a special Nightly browser [1][2]. Windows > Users: We are actively working on Windows support and will send more > communication once it is available. > > > Hi everyone, > > despite all of our testing efforts, Firefox still sometimes crashes in the > wild and some of these crashes even look like security problems (e.g. > use-after-free or other memory corruptions). Unfortunately, in many of > these cases, the data we have in our crash-stats are not actionable on > their own (i.e. do not provide enough information for a developer to be > able to find and fix the problem). > > In CI and fuzzing, we have been using AddressSanitizer (ASan), a > compile-time instrumentation, very successfully for quite a while now. In > particular the information it provides about use-after-free is much more > actionable than a simple crash stack. > > In order to leverage the combined power of Nightly testing and ASan, we > have come up with a special ASan Nightly build [1] that is equipped with a > special ASan reporter addon. This addon is capable of collecting and > reporting ASan errors back to us, once they are detected. We hope to find > such errors in the wild and then use the ASan error report to identify and > fix the problem, even though it might not be reproducible. > > Of course this approach comes with a drawback: While ASan’s performance is > really good, its memory usage is significantly higher compared to a regular > Nightly browser. Furthermore, ASan needs to retain free’d memory for a > while in order to detect use-after-free on it. Hence, running such a build > requires you to have enough RAM (at least 16 GB is recommended) and restart > the browser once or twice a day. > > This project can only succeed if enough people are using it. So if you > meet the requirements, I would be very happy if you joined the project [2]. > > Thanks! > > - Chris (:decoder) > > [1] > https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-63.0a1.en-US.linux-x86_64-asan-reporter.tar.bz2 > > [2] > https://developer.mozilla.org/en-US/docs/Mozilla/Testing/ASan_Nightly_Project > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: block audible autoplay media intervention
On Fri, 6 Jul 2018, at 15:35, Chris Pearce wrote: > On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote: > > On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote: > > > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote: > > > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote: > > > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still > > > > > > > allowed to play. > > > > > > > > > > > > Chrome and Safari allows autoplay only when the playback is muted. > > > > > > The > > > > > > spec allows side effect for setting `muted = false;`. What will > > > > > > happen for > > > > > > a website that changes the volume from 0 to something else? > > > > > > > > > > > > > > > > > > > > > > If an HTMLMediaElement starts playing with muted/volume=0 and then > > > > > script > > > > > sets it to unmuted/volume>0, then we'll pause the media. > > > > > > > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it > > > > be worth only use muted for consistency between browsers? > > > > > > This code gives me the impression that WebKit does in fact block volume > > > > 0 media: > > > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303 > > > > > > So maybe Blink should consider changing to be consistent with other > > > browsers? ;) > > > > That's interesting. We spec'd something in HTML and Safari did not mention > > this. It's not in their documentation nor ours. What's the benefit of > > allowing volume=0 to autoplay? > > > Setting volume to 0 is another easy way to make videos inaudible, and we > want inaudible video to be able to autoplay. So I'd flip that question > around and ask why you think volume=0 video should not autoplay but a > video without an audio track should? Both are inaudible. `muted` and the presence of an audio track clear distinguishable signals as they are boolean and declarative. A video that has volume 0 could be for various reasons. Furthermore, requiring `muted` or `volume` seems slightly odd as they both apply to the HTML content while the audio track metadata is at a different level so can offer benefits if for example, modifying the content is possible but not the page. FWIW, we could add this in Blink if it can help with x-browser compat but I've never heard of a website asking for this nor did I see articles suggesting using volume=0 even from Apple. Given that it would require the website to set `video.volume = 0;` in script, it is less powerful than `muted` that can be used as a content attribute too. > > > > > > Also, will autoplay be allowed when the video has no audio track? > > > > > > > > > > > > > > > > > > > > > > > Our autoplay logic ignores whether the media resource has an audio > > > > > track; > > > > > it makes our implementation simpler, and if an author knows a media > > > > > should > > > > > be inaudible, they can set the muted attribute. So a video element > > > > > playing > > > > > a media resource with no audio track and without the muted attribute > > > > > would > > > > > still be blocked. > > > > > > > > FWIW, WebKit uses the audio track availability and Blink intends to do > > > > this at some point. > > > > > > > > > I actually implemented this, landed it, and then ended up reverting it. > > > > > > The main problem here is if HTMLMediaElement.play() is called before the > > > load algorithm has reached readyState>=HAVE_METADATA, you won't know > > > whether the media you're loading has audio tracks. > > > > > > If you hit this case, you have two options; decide whether to block > > > immediately based on incomplete information, or return the promise and > > > wait until you reach loadedmetadata before deciding whether to play. > > > > > > If you decide based on incomplete information you become racy; the > > > decision you make on incomplete information may contradict the decision > > > you'd make based on more complete information when the load is further > > > along, and network loads are inherently racy. That seems bad. > > > > > > If you return the promise and yield control to JS you run into compat > > > issues. As Jean-Yves mentioned, some sites expect that > > > HTMLMediaElement.play() synchronously sets the paused attribute to false > > > and enqueues tasks to fire "play", "playing" etc. Safari appears to have > > > a quirks mode where they pretend to play and then dispatch "playing" and > > > "pause" if they reach readyState HAVE_METADATA and they discover an > > > autoplaying media has an audio track (even if they didn't play, they'll > > > dispatch playing). > > > > > > Experimenting with such hacks in Gecko led to compat issues. Even > > > without such hacks I still ran into many subtle problems caused by > > > timing changes due to the play/playing events being dispatched later on > > > in the load, and by the paused attribute changing at a later
Re: Intent to implement: Scrollbar color properties
Hi Xidorn, > On Jul 8, 2018, at 8:24 PM, Xidorn Quan wrote: > Hopefully with these properties (and one another controlling scrollbar width > or style to fulfill thin scrollbar usecases), WebKit and Blink would be able > to unship their current pseudo-elements, so that we wouldn't need to > implement them to get web compatible. I’m skeptical about this approach, given that it requires existing and legacy sites to update their code. But I would be happy to be wrong. ^__^ To date the compat issues we care about (because they break layouts) are about assigning a specific width, or hiding the track entirely (via ::-webkit-scrollbar). > Platform coverage: Desktop Why not on mobile? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor wrote: > Hi Xidorn, > >> On Jul 8, 2018, at 8:24 PM, Xidorn Quan wrote: >> Hopefully with these properties (and one another controlling scrollbar width >> or style to fulfill thin scrollbar usecases), WebKit and Blink would be able >> to unship their current pseudo-elements, so that we wouldn't need to >> implement them to get web compatible. Thanks Xidorn! > I’m skeptical about this approach, given that it requires existing and legacy > sites to update their code. But I would be happy to be wrong. ^__^ MS Edge disagrees as they have been able to *drop* their legacy proprietary -ms- prefixed properties for scrollbar coloring (which was often provided as a back-up in ::-webkit- scrollbar code samples) with very little impact on apparent bugs / compat from their perspective. We confirmed this last week at the CSSWG meeting with MS Edge PMs. Waiting on the official f2f minutes for a citation. > To date the compat issues we care about (because they break layouts) are > about assigning a specific width, or hiding the track entirely (via > ::-webkit-scrollbar). Agree with the use-cases "specific width, or hiding the track entirely" and the new (not yet implemented) scrollbar-width property addresses those. https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width Also we are getting strong informal signals (reconfirmed as of last week) that there is high desirability to DROP the mess of ::-webkit-scrollbar-* from existing implementations. This is a when not if, and is largely waiting on sufficient proof of concept that CSS Scrollbars solves enough use-cases to get at least some sites to switch or provide both, which likely depends on us shipping the new standard properties. Past evidence (which shows how this has changed to be even more negative on webkit-scrollbars over the past year) until we get last week's minutes: https://lists.w3.org/Archives/Public/www-style/2017May/0010.html "smfr: It was a mistake to leak to web. We don't really like that people can style scrollbars. We won't enhance and prefer to deprecate it." https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html "TabAtkins: We would like to drop as much of our weird -webkit- stuff as possible." ... "smfr: We're interested only in very limited customization of scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff. smfr: we're only interested in coloring, and hiding scrollbars." Not quite an official intent to deprecate / unship, but clearly that's the direction things are headed. >> Platform coverage: Desktop > > Why not on mobile? Requires platform specific code that just hasn't been written (yet) for mobile platforms. Do you think this feature requires Desktop+Mobile parity/equivalency before we ship on Desktop? Thanks, Tantek ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
Hi Tantek, > On Jul 9, 2018, at 4:36 PM, Tantek Çelik wrote: > > On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor wrote: >> Hi Xidorn, >> >>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan wrote: >>> Hopefully with these properties (and one another controlling scrollbar >>> width or style to fulfill thin scrollbar usecases), WebKit and Blink would >>> be able to unship their current pseudo-elements, so that we wouldn't need >>> to implement them to get web compatible. > > Thanks Xidorn! > > >> I’m skeptical about this approach, given that it requires existing and >> legacy sites to update their code. But I would be happy to be wrong. ^__^ > > MS Edge disagrees as they have been able to *drop* their legacy > proprietary -ms- prefixed properties for scrollbar coloring (which was > often provided as a back-up in ::-webkit- scrollbar code samples) with > very little impact on apparent bugs / compat from their perspective. > > We confirmed this last week at the CSSWG meeting with MS Edge PMs. > Waiting on the official f2f minutes for a citation. That’s a very cool signal. > > >> To date the compat issues we care about (because they break layouts) are >> about assigning a specific width, or hiding the track entirely (via >> ::-webkit-scrollbar). > > Agree with the use-cases "specific width, or hiding the track > entirely" and the new (not yet implemented) scrollbar-width property > addresses those. > > https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width > > Also we are getting strong informal signals (reconfirmed as of last > week) that there is high desirability to DROP the mess of > ::-webkit-scrollbar-* from existing implementations. This is a when > not if, and is largely waiting on sufficient proof of concept that CSS > Scrollbars solves enough use-cases to get at least some sites to > switch or provide both, which likely depends on us shipping the new > standard properties. > > Past evidence (which shows how this has changed to be even more > negative on webkit-scrollbars over the past year) until we get last > week's minutes: > > https://lists.w3.org/Archives/Public/www-style/2017May/0010.html > "smfr: It was a mistake to leak to web. We don't really like that > people can style scrollbars. We won't enhance and prefer to deprecate > it." > > https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html > "TabAtkins: We would like to drop as much of our weird -webkit- stuff > as possible." > ... > "smfr: We're interested only in very limited customization of > scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff. > smfr: we're only interested in coloring, and hiding scrollbars." > > Not quite an official intent to deprecate / unship, but clearly that's > the direction things are headed. Also positive signals. Typically Apple doesn’t drop support for anything that has shipped, at risk of breaking sites… so we’ll have to see how that evolves going forward. > > >>> Platform coverage: Desktop >> >> Why not on mobile? > > Requires platform specific code that just hasn't been written (yet) > for mobile platforms. > > Do you think this feature requires Desktop+Mobile parity/equivalency > before we ship on Desktop? Thanks. If we have plans to ship on mobile in the future, I would say no. I was mostly curious if this was considered as a “Desktop”-only feature. Thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
On Tue, Jul 10, 2018, at 7:36 AM, Tantek Çelik wrote: > >> Platform coverage: Desktop > > > > Why not on mobile? > > Requires platform specific code that just hasn't been written (yet) > for mobile platforms. Actually I don't really have a plan to support the rendering part of scrollbar color properties on Android. Do you think we should have it? I don't see any evidence that scrollbar there is a problem for people on mobile. People may want to hide the scrollbar at the end, but other than that, scrollbar styling probably isn't something highly desired. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
