Firefox no longer opens Excel Spreadsheets with Multiple Worksheets
Categories
(Core :: DOM: Navigation, defect, P1)
Tracking
()
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.
- In Excel, Spreadsheets can be saved as HTML Files
- Firefox can then browse the Spreadsheets like any other HTML File.
- Excel Spreadsheets with multiple Worksheets, saved as Web Pages, have a Tab Bar added to the bottom that be used to access other Worksheets.
- 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.
- 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.
Updated•2 months ago
|
Comment 1•2 months ago
|
||
ni? myself to try to attach one of those export html files to this bug, which would help.
Comment 2•2 months ago
|
||
(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!
Comment 3•2 months ago
|
||
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.
Comment 4•2 months ago
|
||
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?
I am just seeing this request for sample. Let me know if anything is still needed.
Thanks!
Comment 6•2 months ago
|
||
(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.
Comment 7•2 months ago
|
||
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.
Comment 9•2 months ago
|
||
Set release status flags based on info from the regressing bug 1879820
Comment 10•2 months ago
|
||
(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.
Updated•2 months ago
|
Updated•2 months ago
|
Description
•