Closed Bug 1940868 Opened 2 months ago Closed 2 months ago

Firefox no longer opens Excel Spreadsheets with Multiple Worksheets

Categories

(Core :: DOM: Navigation, defect, P1)

Firefox 134
defect

Tracking

()

RESOLVED DUPLICATE of bug 1934807
Tracking Status
firefox-esr128 --- unaffected
firefox134 --- fixed
firefox135 --- fixed
firefox136 --- fixed

People

(Reporter: erikesq777, Unassigned)

References

()

Details

(Keywords: regression, webcompat:site-report)

User Story

platform:windows,mac,linux,android
impact:workflow-broken
configuration:general
affects:all
branch:release
diagnosis-team:webcompat

Attachments

(1 file)

7.38 KB, application/x-zip-compressed
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

I upgraded to Firefox 134. This problem does not occur with Earlier Versions of Firefox.

  1. In Excel, Spreadsheets can be saved as HTML Files
  2. Firefox can then browse the Spreadsheets like any other HTML File.
  3. Excel Spreadsheets with multiple Worksheets, saved as Web Pages, have a Tab Bar added to the bottom that be used to access other Worksheets.
  4. Prior to updating to Firefox 134, Firefox could be used to use the Tab Bar to access the other Worksheets. Now in Firefox 134, the links to other Worksheets with in a Spreadsheet no longer function.
  5. This is a serious problem for Users who use Firefox to Browse Excel Spreadsheets with multiple Worksheets.

Actual results:

Clinking on the Link to other Worksheets with in an Excel File that has been saved as HTML, should open the other Link / Worksheet. Now nothing happens when clicking on the link within the HTML File to the other Worksheet.

Expected results:

The link to other Worksheets within the Excel File that has been saved as HTML should open the other Worksheets.

Component: Untriaged → Site Reports
Product: Firefox → Web Compatibility

ni? myself to try to attach one of those export html files to this bug, which would help.

Severity: -- → S2
User Story: (updated)
Flags: needinfo?(dschubert)
Priority: -- → P1

(In reply to Dennis Schubert [:denschub] from comment #1)

ni? myself to try to attach one of those export html files to this bug, which would help.

Perhaps the reporter could help with that, too.

Reporter: would you be willing to generate an export that reproduces the problem for you, and attach it (or a zipped version of it, if there are multiple files involved) as an attachment on this bug? (There should be an "Attach New File" button just above your first comment here.)

Thanks!

Flags: needinfo?(erikesq777)
Attached file excel_to_html.zip

I have the same problem as OP. I've attached example html page exported from Excel.

In Firefox 134 nothing happens when navigation tab on the bottom of the page is clicked.
In Firefox 133 navigation tabs work properly and content of the page changes after clicking the tab.

Both Firefox 134 and 133 show error "Uncaught DOMException: Permission denied to access property "g_iIEVer" on cross-origin object" after opening html file exported from Excel that has at least one navigation tab on the bottom. In Firefox 133 the same error is shown after every click on navigation tab but it doesn't seem to couse reported problem.

No "DOMException" error is shown in console and navigation tabs start to work in Firefox 134 if preference "security.fileuri.strict_origin_policy" is set to false.

Thanks. I can reproduce with that testcase. (clicking "sheet1" / "sheet2" at the bottom do not change the text at the top)

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9842b7d18aa34aca3b8542bffdf5e932435ddf4e&tochange=e139b4496f0b074613eb0cee9349b23bfacb843b

Edgar, could you take a look?

Flags: needinfo?(echen)
Regressed by: 1879820

I am just seeing this request for sample. Let me know if anything is still needed.

Thanks!

Flags: needinfo?(erikesq777)

(In reply to Erik from comment #5)

I am just seeing this request for sample. Let me know if anything is still needed.

Thanks! We're all set with comment 3, I think.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Ah, this works correctly in today's Nightly, so this is probably a version of bug 1934807 (which has the same regressor), whose fix just recently landed.

Depends on: 1934807

Yes, I think this is a duplicate of bug 1934807.

Flags: needinfo?(echen)

Set release status flags based on info from the regressing bug 1879820

(In reply to Edgar Chen [:edgar] from comment #8)

Yes, I think this is a duplicate of bug 1934807.

Confirmed - mozregression --find-fix gives me
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cc9a9ff879b0ac9c7a76753422060c13fd997d83&tochange=a278f9295b80348d58b343d9cdfa4fbcffe2ac32
which says bug 1934807 fixed this.

Let's just mark as a dupe. Looks like a fix will be likely on the way in 135 and maybe in a 134 dot release, per uplift requests in bug 1934807 comment 26.

Status: NEW → RESOLVED
Closed: 2 months ago
Component: Site Reports → DOM: Navigation
No longer depends on: 1934807
Duplicate of bug: 1934807
Flags: needinfo?(dschubert)
Product: Web Compatibility → Core
No longer regressed by: 1879820
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: