User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160922113459 Steps to reproduce: Log in to https://www.scoutbook.com/mobile/ Navigate to unit calendar (Scoutbook is a Boy Scout tracking tool). Actual results: The color bar for events is not displayed. This makes it appear as if the events are no longer on the calendar. Expected results: Color bar with event descriptions should appear on the calendar. This worked on Firefox 48 and earlier. It fails on Firefox 49.0.1 for both Windows and Mac. The event is shown in a colored bar with white text.

I did some additional testing. When I click where the calendar entry should be (below the date), the correct entry description is open. This says to me the problem is the background color of the text field is not rendering. Since Scoutbook uses white text on a colored background for calendar events, it makes the event appear as if it has been deleted.

Hi Ed, I try to test this on Mac OS X 10.10 with FF 49 release but I have a problem. I created an account on https://www.scoutbook.com/mobile/ I logged in but I can't see any calendar. There should be a action that I need to do to see the calendar? Can you please make a screen recorder for a better understanding, maybe this link can help you to do this: http://screencast-o-matic.com/home. You can attached the video to this bug report. I want to ask you if you can to try several thinks to see if you can still reproduce it: 1. Please download the Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem. 2. If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager 3. Please test if the issue can be reproduced in the safe mode of Firefox: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Hi Ovidiu, I tried your tests 1 through 3 and still see the issue. I will create an account for you on the Scoutbook test system and provide instructions on how to see the issue. I'm traveling on business this week so I will get to it as soon as I can and update this bug report. Thanks for the help, Ed

Hi Ed, Thank for your replay, that sounds grate. It will be better this way because from your report this issue seams to be a regression.

Hi Ovidiu, I have created an account on the Scoutbook test system for this bug. I will send you an e-mail with the login infomration. To see the issue, click on My Dashboard -> Pack 260 -> Upcoming Events. You should see events on Sept 27, 28 and Oct 1, 3 in the calendar view. With Firefox 49 they do not appear. Ed

I marked comment 7 as private so that the bug can remain otherwise open.

We have reports from Scoutbook users that this is now occurring in the mobile versions of Firefox as well. Given the comment above that this is in core, it makes sense to me but I wanted to note it here. Ed

I'm working on a reduced testcase... I'll post that shortly.

OK, it looks like the problem is from the declaration... "-webkit-box-sizing: content-box" ...on a rule for ".dw-cal-day .dw-i". That rule is shown as being struck out (i.e. ignored) in Chrome's devtools, for some reason (along with all the other "box-sizing" rules applied to that element). Not sure why. But Firefox is honoring it, and that means sizing ends up working differently.

I'm not sure comment 11 is 100% of the problem, though -- because I can give that element style="box-sizing: content-box" in Chrome, and it accepts that style and yet doesn't change the rendering...

Here's a partially-reduced testcase (still a lot of cruft, worth reducing further if someone can take a crack at it). Mike, could you pick this up from here perhaps? I'm out for the rest of the week so I can't put too much time into this at the moment. Ed: If you're looking for a quick fix/workaround on your end, I *think* it should work if you remove the declaration rule that I mentioned in comment 11. (And we can still proceed on figuring out stuff further on our end, using my attached testcase.)

Daniel, Thank you. I will pass your quick fix/workaround on to the Scoutbook developers.

Happy to dig in (recovering from 2 days off, so still in email backlog mode), will have more time tomorrow-ish. (leaving ni? so it stays on my radar)

Thanks, Ed & Mike! Ed, for what it's worth: I verified that the ".dw-cal-day dw-i" -webkit-box-sizing:content-box declaration doesn't impact the rendering in Google Chrome and Edge (and presumably Safari as well since it still behaves pretty similarly to Chrome due to the browser-engine-ancestry). So, I do think the developers can safely remove that line without impacting the experience for users on other browsers at all. And I believe that is the specific declaration which is causing us to mis-render, starting in Firefox 49 -- at least, if I disable webkit prefix support via the about:config pref (and make the site render nicely as it used to), I can break it again by adding unprefixed "box-sizing: content-box" to that same CSS rule. So, that one declaration is sufficient to explain the breakage in Firefox. There's some remaining subtlety to *why* that declaration causes a behavior difference in Firefox but not in other browsers. But I think that answers the "why did this break" question, at least proximally. (We can sort out the remaining subtlety by ripping out more from the attached reduced testcase until we've got something smaller that makes more sense.)

Too late for a fix in 49, marking fix-optional for 50 since there is a workaround.

Seems unlikely we're going to get an in-product fix in place in time to consider backporting to 51/52, but leaving it on the fix-optional radar just in case.

Given that site developers can do something here and it seems edge-case-y, how important is it that we try for a Gecko fix?

I'd like to try for a fix, though other things have been occupying my attention. (And I'm out for a few days starting tomorrow, so I can't commit to diving in right now.) RE importance: it's heartening that we're only aware of one instance of breakage & that site developers can work around it if they like. Per comment 16, I'm unclear why exactly stuff's breaking, so there's still some mystery here. It is a regression, so ideally it is something we should try to fix (or at least better-understand).

(In reply to Daniel Holbert [:dholbert] (vacation, returning 2/27) from comment #20) > I'd like to try for a fix [...] > > [...] there's still some mystery > here. It is a regression, so ideally it is something we should try to fix > (or at least better-understand). OK, sounds like a fix-optional for at least 53 and probably 54 (but we can change that if necessary). Thanks!

scoutbook.com appears to be down ATM, but I should be able to get access to an account (I'm involved with cubs, and I'm pretty sure our scout troop has a scoutbook account). ni? self to check back in a week or so.

Scoutbook.com is working. There have been intermittent issues recently but I have been able to get to the system without trouble.

Just verified that this still reproduces, and removing -webkit-box-sizing: content-box; from the following rule still fixes the issue: .dw-cal-day .dw-i { margin: 0; padding: 5px; padding-top: 5px; padding-bottom: 5px; border: 0; overflow: visible; -webkit-box-sizing: content-box; } (https://www.scoutbook.com/includes/mobile-concat.css isn't behind any kind of auth) I went to fill in a contact form and found the following forum message (kind of wish I had done this... a long time ago >_<), I see Ed D has been active in :) https://www.scoutbook.com/mobile/forums/bugs/93501/firefox-50-and-calendar-events-not-appearing/

Here's a more-reduced testcase. In Firefox, the orange area protrudes from the black border. In Chrome and Edge, it does not.