1373548 - Word Online in OneDrive doesn't render properly

Status: RESOLVED FIXED

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

Description

[Rahul]

Attachment: Screenshot from 2017-06-16 12-34-50.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608175746

Steps to reproduce:

I opened a Word document in Word Online (OneDrive).


Actual results:

The background for the document is gray. I've attached a screenshot. I'm using Firefox 54 on Debian 8.


Expected results:

The background should be white, which is the case in other browsers.

Comment 1

[Loic]

Does it happen with previous versions of Firefox?

Comment 2

[Rahul]

(In reply to Loic from comment #1)
> Does it happen with previous versions of Firefox?

No, I've checked this on a Windows 7 Enterprise machine with Firefox 53.0.3 (32-bit), and it seems to render fine.

Comment 3

[Loic]

As I don't have Office 360 to reproduce and test the issue, could you use yourself the tool mozregression to narrow down a regression range in FF54, please.

See http://mozilla.github.io/mozregression/ for details to use it on Linux (it's easy).
Run the command "mozregression --good=53" (or older like --good=52) then for each nightly build downloaded by the tool, make the test and enter if the build is good or bad. Then paste here the final pushlog.

If you need to verify if it's fixed or not in the current nightly, you can use the command "mozregression --launch=2017-06-17" (with the date of today).

Comment 4

[Rahul]

Hmm I tried with --good=53, and I'm attaching the output here:

rahul@rahul-pc:~$ mozregression --good=53
 0:00.88 INFO: No 'bad' option specified, using 2017-06-17
 0:00.88 INFO: Using date 2017-01-23 for release 53
 0:09.37 INFO: Testing good and bad builds to ensure that they are really good and bad...
 0:09.37 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2017/01/2017-01-23-16-35-59-mozilla-central/firefox-54.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
 1:09.78 INFO: Running mozilla-central build for 2017-01-23
 2:03.26 INFO: Launching /tmp/tmpiUX2fL/firefox/firefox
 2:03.26 INFO: Application command: /tmp/tmpiUX2fL/firefox/firefox -profile /tmp/tmp1Ps7mu.mozrunner
 2:03.29 INFO: application_buildid: 20170123163559
 2:03.29 INFO: application_changeset: 5a4412474c63e1d9e66036d603ac42e9cb2b9150
 2:03.29 INFO: application_name: Firefox
 2:03.29 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 2:03.29 INFO: application_version: 54.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): bad
 4:18.21 ERROR: Build was expected to be good! The initial good/bad range seems incorrect.

I'll run it for 52 and the current nightly

Comment 5

[Loic]

Yes, if the start build which should be good appears to be bad, just try an older version, it's better to start with a larger range for the dichotomy.

Comment 6

[Rahul]

How do I change the range?

Btw, here's the output for --good=52

===== Downloaded 100% =====
 1:09.09 INFO: Running mozilla-central build for 2016-11-14
 1:52.55 INFO: Launching /tmp/tmpr1gmOY/firefox/firefox
 1:52.55 INFO: Application command: /tmp/tmpr1gmOY/firefox/firefox -profile /tmp/tmpbK6eVM.mozrunner
 1:52.57 INFO: application_buildid: 20161114043454
 1:52.58 INFO: application_changeset: a516c754042c438a5c1499171ca525a980ecb911
 1:52.58 INFO: application_name: Firefox
 1:52.58 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 1:52.58 INFO: application_version: 53.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): 
 4:29.75 WARNING: Process exited with code 234
bad
 4:33.63 ERROR: Build was expected to be good! The initial good/bad range seems incorrect.

Running with --launch=2017-06-17 also had the same problem with the gray background. The output is here:

rahul@rahul-pc:~$ mozregression --launch=2017-06-17
 0:02.53 INFO: Using local file: /home/rahul/.mozilla/mozregression/persist/2017-06-17--mozilla-central--firefox-56.0a1.en-US.linux-x86_64.tar.bz2
 0:02.53 INFO: Running mozilla-central build for 2017-06-17
 0:51.46 INFO: Launching /tmp/tmpr1h4z3/firefox/firefox
 0:51.46 INFO: Application command: /tmp/tmpr1h4z3/firefox/firefox -profile /tmp/tmpEKUUX7.mozrunner
 0:51.48 INFO: application_buildid: 20170617100144
 0:51.48 INFO: application_changeset: bb8eab3c3ac4147848c4c85d628ba72029978665
 0:51.48 INFO: application_name: Firefox
 0:51.48 INFO: application_repository: https://hg.mozilla.org/mozilla-central
 0:51.48 INFO: application_version: 56.0a1

Comment 7

[Loic]

The range is your choice --good=date1 --bad=date2.
If 52 is bad, just try an older start date, like --good=50.

That's said, it could be an issue only with Linux.

Comment 8

[Rahul]

Hmm it seems all the Linux builds have the issue. I updated Firefox on the Windows machine to 54.0 (32-bit) and that worked fine.

Comment 9

[Loic]

Maybe Office 360 is applying bad UA sniffing. In your profile on Linux, could you install the add-on "User Agent Switcher" (https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/) and change the UA to the UA for Windows (FF54 32b, Win 7 64b):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0

Comment 10

[Rahul]

It didn't work, but I could've done it wrong. I installed the extension, restarted FF, created a new UA, so my UA looks like this:

Description: UA for Windows
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
App Code Name: Mozilla
App Name: Netscape
App Version: 5.0 (X11)
Platform: Windows (I changed this too)
Vendor:
Vendor Sub:

Comment 11

[Loic]

Well, it could be an issue with Office 360 and Linux.

Comment 12

[Rahul]

Perhaps. It's interesting though, the issue is only with Word and not Excel and the other apps.

Comment 13

[Loic]

Makoto, do you have still Office 365 to test?

Desigan, as it could be a TE bug on Microsoft side, I add you in the CC list.

Comment 14

[Rahul]

No, this isn't from Office 365, this is from OneDrive, which comes with an Outlook account (like Google Drive comes with GMail)

Comment 15

[Alice0775 White]

WordEditor.css uses |background-color: window;| on Windows10 and Ubuntu16.04.

div.OutlineContainer {
    left: 0;
    top: 0;
    position: relative;
    border-color: #ababab;
    border-left-style: solid;
    border-right-style: solid;
    color: WindowText;
    background-color: window;
}

Comment 16

[Makoto Kato [:m_kato]]

(In reply to Loic from comment #13)
> Makoto, do you have still Office 365 to test?

My trial account is expired, but this seems to occur on free account (Word Online?) although I don't test it yet.

Comment 17

[Makoto Kato [:m_kato]]

Alice-san, thanks.  I confirmed on Ubuntu 16.04 + Nightly.  This seems to be compatibility issue.

Comment 18

[Carmen Fat [:cfat] - Ecosystem QA]

Since I managed to reproduce the issue on Nightly 15.0a1 (2012-06-02) using Ubuntu 16.04 x64, this doesn't seem to be a regression.
Based on these results and comment 8, I'm removing the regressionwindow-wanted keyword.

Comment 19

[Makoto Kato [:m_kato]]

As long as comment #15, this seems to be web compatibility issue.  Could you or your team handle this ?

Comment 20

[Mike Taylor [:miketaylr]]

Sure thing, thanks!

Adam, can you reach out to Microsoft here?

Comment 21

[Adam Stevenson [:adamopenweb]]

Reaching out via the Microsoft mailing list.

Comment 22

[Kate Manning [:laghee]]

Attachment: bug1373548.patch

I was able to reproduce this on Ubuntu 18.04, and this patch sets the `window` system color default to white, which works for me locally to fix the issue.

Comment 23

[Karl Tomlinson (:karlt)]

Comment on attachment 8996075 [details] [diff] [review]
bug1373548.patch

The purpose of the window system color is to return the system window background color.  There are certainly good reasons to stop supporting this in content, but that would need to be consistent for all colors, we'd need a replacement theme, and it would be only for content, not the browser chrome.

https://bugzilla.mozilla.org/show_bug.cgi?id=1411425#c28
https://docs.google.com/document/d/1eKlYHx2X8aqkcxl6hbQcKUvg3rhASRlKnj_o5HFjZ5Q/edit

Comment 24

[Yuri Khan]

I think Word is doing the right thing here. By setting both background-color: window and color: WindowText, it’s saying “I want  to respect the user’s preferred theme settings”.

Word Online is not content. It is an application. It has all the reasons to want to intergate with the user’s desktop theme for applications.

Comment 25

[Mike Taylor [:miketaylr]]

(In reply to Yuri Khan from comment #24)
> I think Word is doing the right thing here. By setting both
> background-color: window and color: WindowText, it’s saying “I want  to
> respect the user’s preferred theme settings”.

This bug isn't about what Word is doing. Firefox on Linux is the only browser that gets a non-white background. Compare to Firefox on Windows and Mac, and then check Chrome. IMO, this is a theme bug.

> Word Online is not content. It is an application. It has all the reasons to
> want to intergate with the user’s desktop theme for applications.

(I'm not sure what this means)

Comment 26

[Yuri Khan]

(In reply to Mike Taylor [:miketaylr] (62 Regression Engineering Owner) from comment #25)
> (In reply to Yuri Khan from comment #24)
> > I think Word is doing the right thing here. By setting both
> > background-color: window and color: WindowText, it’s saying “I want  to
> > respect the user’s preferred theme settings”.
> 
> This bug isn't about what Word is doing. Firefox on Linux is the only
> browser that gets a non-white background. Compare to Firefox on Windows and
> Mac, and then check Chrome. IMO, this is a theme bug.

When you say “Firefox on (Windows|Mac)”, do you mean “Firefox on (Windows|Mac) with default theme” or “Firefox on (Windows|Mac) with a custom theme specifying non-white window background”?

A special case of a custom theme with a non-white window background is a high contrast theme with white text on black background. People choose that when they have a health condition that makes it painful to look at large areas of white.

As long as Firefox continues to support CSS 2 System colors, it should keep mapping them to theme colors as faithfully as possible. It is a strength in comparison with other browsers, not a bug.

Comment 27

[Mike Taylor [:miketaylr]]

(In reply to Yuri Khan from comment #26)

> When you say “Firefox on (Windows|Mac)”, do you mean “Firefox on
> (Windows|Mac) with default theme” or “Firefox on (Windows|Mac) with a custom
> theme specifying non-white window background”?

Default themes.

> A special case of a custom theme with a non-white window background is a
> high contrast theme with white text on black background. People choose that
> when they have a health condition that makes it painful to look at large
> areas of white.

Sounds reasonable, yes.

> As long as Firefox continues to support CSS 2 System colors, it should keep
> mapping them to theme colors as faithfully as possible. It is a strength in
> comparison with other browsers, not a bug.

I'm not sure I agree, when we're the one browser displaying what appears to be a broken word online experience.

Comment 28

[Yuri Khan]

(In reply to Mike Taylor [:miketaylr] (62 Regression Engineering Owner) from comment #27)
> (In reply to Yuri Khan from comment #26)
> 
> > When you say “Firefox on (Windows|Mac)”, do you mean “Firefox on
> > (Windows|Mac) with default theme” or “Firefox on (Windows|Mac) with a custom
> > theme specifying non-white window background”?
> 
> Default themes.

Then the comparison is flawed.

If I were triaging this bug report, after finding out that Word Online uses system colors, I would ask the reporter to provide a screenshot of the default text editor for their desktop environment. Chances are, we would see the exact same shade of gray. Then I’d say, “See, it’s working as intended”. Bug closed. If you don’t like gray backgrounds in general, change your GTK+3 theme.

> > A special case of a custom theme with a non-white window background is a
> > high contrast theme with white text on black background. People choose that
> > when they have a health condition that makes it painful to look at large
> > areas of white.
> 
> Sounds reasonable, yes.
> 
> > As long as Firefox continues to support CSS 2 System colors, it should keep
> > mapping them to theme colors as faithfully as possible. It is a strength in
> > comparison with other browsers, not a bug.
> 
> I'm not sure I agree, when we're the one browser displaying what appears to
> be a broken word online experience.

Well, it is arguably a more severe bug when the user explicitly requests white text on black background (by choosing a high contrast dark theme), a web application explicitly attempts to honor that request (by using Window/WindowText colors, and the browser instead assaults the user with a white background.

Support for system colors is an accessibility feature. One does not simply remove accessibility features.

Comment 29

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 30

[Jeffrey Ethelred]

If fixed the dark background of Word in Office online by going into about:config and changing the following tag to true:
ui.use_standins_for_native_colors = true

Comment 31

[ovf]

(In reply to Karl Tomlinson (:karlt) from comment #23)

The purpose of the window system color is to return the system window
background color.

CSS Color Module Level 4 clarifies[1] that 'Window' is the same as 'Canvas', which is defined[2] as "Background of application content or documents" and rendered as white in the specification. This matches what Microsoft is expecting, as well as other browsers' behaviour.

Likely moving 'case ColorID::Window:' from 'aColor = mMozWindowBackground;' to 'aColor = mFieldBackground;' in widget/gtk/nsLookAndFeel.cpp will get the behaviour closer to the expected one.

1 https://www.w3.org/TR/css-color-4/#window
2 https://www.w3.org/TR/css-color-4/#valdef-system-color-canvas

Comment 32

[Raul Bucata]

I was not able to reproduce the issue. The background in the Word Online document is displayed as expected:

https://prnt.sc/E0gHaEPV1VvK

Rahul, is the issue still reproducible on your side?

Tested with:

Browser / Version: Firefox Nightly 100.0a1 (2022-03-28) (64-bit)
Operating System: Ubuntu 20.4 LTS x64

Comment 33

[Rahul Yedida]

(I've lost access to my previous account because of 2FA, so this is a new account).

Unfortunately, I do not have access to a Linux system at this time. On my Mac, I cannot reproduct this issue, and it seems like that is also true for your Ubuntu system. Perhaps this issue is fixed?

Comment 34

[Raul Bucata]

I can confirm. Closing this as FIXED