Closed Bug 1307118 Opened 8 years ago Closed 4 years ago

Firefox 49 Does not Show Events in Scoutbook Calendar (background color of text field not rendering)

Categories

(Web Compatibility :: Site Reports, defect, P3)

defect

Tracking

(firefox49 wontfix, firefox50 wontfix, firefox51 fix-optional, firefox52 fix-optional, firefox53 fix-optional, firefox54 fix-optional)

RESOLVED FIXED
Tracking Status
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- fix-optional
firefox52 --- fix-optional
firefox53 --- fix-optional
firefox54 --- fix-optional

People

(Reporter: edavignon, Unassigned)

References

Details

(Keywords: regression, webcompat:site-wait, Whiteboard: [sitewait][webcompat])

Attachments

(4 files)

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.
Summary: Firefox 49 Does not Show Events in Scoutbook Calendar → Firefox 49 Does not Show Events in Scoutbook Calendar (background color of text field not rendering)
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
Flags: needinfo?(edavignon)
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
Blocks: 1213126
Group: mozilla-employee-confidential
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Flags: needinfo?(edavignon) → needinfo?(dholbert)
Keywords: regression
Product: Firefox → Core
Version: 49 Branch → Trunk
Group: mozilla-employee-confidential
I marked comment 7 as private so that the bug can remain otherwise open.
Flags: needinfo?(miket)
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.
Flags: needinfo?(dholbert)
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.)
Attachment #8800308 - Attachment description: testcase 1 (partially reduced) → testcase 1 (partially reduced): Text is inside black border on Chrome, but outside on Firefox w/ webkit-prefix support
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)
Flags: needinfo?(miket)
Whiteboard: [needsdiagnosis][webcompat]
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.
Priority: -- → P3
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?
Flags: needinfo?(dholbert)
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).
Flags: needinfo?(dholbert)
(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.
Flags: needinfo?(miket)
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/
Flags: needinfo?(miket)
Here's a more-reduced testcase. In Firefox, the orange area protrudes from the black border. In Chrome and Edge, it does not.
Component: Layout → Layout: Tables
Whiteboard: [needsdiagnosis][webcompat] → [sitewait][webcompat]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

See bug 1547409. Moving webcompat whiteboard tags to keywords.

My kids aren't involved in scouting anymore, so I can't verify if this still reproduces, but based on Comment #24, I can see the rule no longer includes -webkit-box-sizing: content-box;.

.dw-cal-day .dw-i{margin:0;padding:5px;border:0;overflow:visible;},

Ed, are you able to verify?

Webcompat Priority: ? → ---
Flags: needinfo?(edavignon)

I do not see the issue with Firefox 72.0.1 on my mac.

Ed

Flags: needinfo?(edavignon)

Sweet, let's call this fixed. Thanks Ed.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

In that case, let's morph this into a WebCompat bug rather than a Core::Layout/Tables bug, since it's fixed via the site itself changing & we didn't actually land a fix in-tree for this (and we still disagree with Chrome on the rendering of the attached testcases).

Component: Layout: Tables → Desktop
Product: Core → Web Compatibility
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: