Open Bug 994306 Opened 11 years ago Updated 1 month ago

In Office Online, word ordering is rearranged in certain RTL text

Categories

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

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 27
Type:
defect

Tracking

(Webcompat Priority:P2, firefox110 affected)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P2
Tracking Flags:
Tracking Status
firefox110 --- affected

People

(Reporter: MSAOfficeWebApps, Assigned: denschub)

References

(
URL
)

Details

(Keywords: webcompat:contact-in-progress, webcompat:site-report, Whiteboard: [webcompat:sightline])

User Story

platform:windows,mac,linux
impact:workflow-broken
configuration:general
affects:some
branch:release
diagnosis-team:layout
outreach-assignee:jfkthame
outreach-last-contacted:2024-10-30

Attachments

(4 files)

RTL_FirefoxVsIE_Footnote.png
7.11 KB, image/png
Details
Screen Recording 2022-04-05 at 16.48.30.mov
7.86 MB, video/quicktime
Details
Screen recording - Chrome.mov
8.54 MB, video/quicktime
Details
Screen Recording 2023-01-16 at 18.09.32.mov
5.85 MB, application/octet-stream
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3; rv:11.0) like Gecko Steps to reproduce: 1. Create a new Word document in Office Online (word.office.com) 2. Set paragraph direction to RTL via the HOME tab in the ribbon 3. Insert a Table 4. Type some text in the table (a few words) 5. Insert a footnote somewhere in the middle of the sentence via the INSERT tab Actual results: Actual: The word ordering gets re-arranged Expected results: Expected: The word ordering stays the same (It does in IE and Chrome)
I can reproduce this bug on my machine: Name Firefox Version 46.0a1 Build ID 20160106030225 User Agent Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Layout: Text
I think this may be a site bug rather than a browser bug. It looks to me like the rearranged text is a result of using unicode-bidi:embed on the <span> for the footnote. AFAICS this property is only applied when using Firefox, thanks to a rule in EditSurface.css that says .FireFox span.TextRun, .FireFox .TextRun > span { unicode-bidi: embed; } (Note that the page has a "FireFox" class, among others, on the <body> tag when running Firefox, and a "Chrome" class when running Chrome; presumably other browsers get their own, too, such as "IE" or "Edge" or whatever...) If I manually add unicode-bidi:embed to the footnote span in Chrome, I see a similarly rearranged rendering of the surrounding text. And conversely, if I disable that rule in Firefox, the text sorts itself out again. So to simplify, what Word is producing under Chrome is equivalent to: data:text/html;charset=utf-8,<div dir=rtl>Hello<span>¹</span> world which renders "Hello¹ world" in either Chrome or Firefox, whereas under Firefox it produces: data:text/html;charset=utf-8,<div dir=rtl>Hello<span style="unicode-bidi:embed">¹</span> world which both browsers render as "world Hello¹". And the question, then, is why Word decides to apply the unicode-bidi property for Firefox, but does not do so for other browsers?

This still reproduces, let's ask Microsoft about it.

URL: https://onedrive.live.com
Component: Layout: Text and Fonts → Desktop
Priority: -- → P3
Product: Core → Web Compatibility
Version: 27 Branch → Firefox 27

The issue seems to be fixed. The text ordering stays the same.
https://prnt.sc/DgtcW8hdNHTP

Tested with:
Browser / Version: Firefox Nightly 101.0a1 (2022-04-04)
Operating System: Windows 10 Pro

Jonathan can you still reproduce this?

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → FIXED

This still reproduces for me in Nightly on macOS.

Status: RESOLVED → REOPENED
Flags: needinfo?(jfkthame)
Resolution: FIXED → ---

Screen recording showing the problem: watch how the text in the table cell flips around when the footnote is inserted (at about 0:26 in the recording).

Inspecting the document with DevTools confirms that the problematic CSS rule (as described in comment 2) is still being inserted.

Severity: normal → S3

Thanks for the report. For me, the issue is reproducible in both Chrome and Firefox.

For this project, we try to focus our effort on layouts, features, or content of the page that works as expected in one browser but not in another.

Reporter, Jonathan can you provide a screen recording where the issue does not reproduce in Chrome?

Tested with:

Browser / Version: Firefox Nightly 110.0a1 (2023-01-11) (64-bit) / Chrome Version 109.0.5414.75 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac OSX Catalina 10.15.7

Status: REOPENED → RESOLVED
Closed: 3 years ago → 2 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → INVALID

Here's a screen recording from Chrome (108.0.5359.124 on macOS) showing that the issue does NOT reproduce for me: when the footnote is inserted in the table cell, the order of the surrounding text remains correct and does not flip over.

Flags: needinfo?(jfkthame)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Thanks for the extra info, Jonathan. The issue is indeed reproducible following the steps to reproduce, either using Tab to insert the text in the middle of the sentence, or by using the mouse.

Tested with:

Browser / Version: Firefox Release 108.0.2 (64-bit)/ Firefox Nightly 110.0a1 (2023-01-16) (64-bit) Chrome Version 109.0.5414.75 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac OSX Catalina 10.15.7

Notes:

  1. Reproducible regardless of the status of ETP.
  2. Reproducible on the latest build of Firefox Nightly and Release.
  3. Works as expected using Chrome.
Assignee: nobody → dschubert
Status: REOPENED → ASSIGNED
status-firefox110: --- → affected

Jonathan, can you check if this still reproduces?

Severity: S3 → S4
User Story: (updated)
Flags: needinfo?(jfkthame)
Keywords: webcompat:site-wait → webcompat:needs-diagnosis, webcompat:site-report

Yes, this still reproduces, similarly to the screen recording in comment 6.

Flags: needinfo?(jfkthame)
OS: Windows 8.1 → All
Hardware: x86_64 → All
User Story: (updated)

This still happens, and AFAICS the diagnosis in comment 2 still applies: Word is serving some CSS that is specifically targeted at Firefox, and results in the broken behavior.

User Story: (updated)
Whiteboard: [webcompat:sightline]
Webcompat Priority: --- → P2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: