1814696 - Filename is malformed in the "What to do with this file"... dialog when a .pdf file starts with a numeric character (or other characters that are directionless)

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P3)

Description

[aoia7rz7l]

Tested on 109.0.

Prerequisites:

Action for pdf file type is set to Always Ask in Preferences > General > Files and Applications > Applications.

(Potential) Prerequisites:

1. pdfjs.disabled is set to true.
2. browser.download.always_ask_before_handling_new_types is set to true.
3. browser.download.useDownloadDir is set to false.

STR:

Download any pdf file from e.g. arxiv.org.

Expected Behavior:

Filename in the Open with... dialog corresponds to the actual filename.

Actual Behavior:

Filename in the Open with... dialog is, for example, pdf.1234.5678 when the actual filename is 1234.5678.pdf. https://mlnsch.files.wordpress.com/2009/08/100-moral-stories.pdf (from bug 1810132) returned moral-stories.pdf-100. This does not affect the subsequent Enter name of file to save to... dialog. Filenames starting with an alphabetic character are not affected. I haven't tested if this also affects other file extensions.

Mozregression returned

Last good revision: 0f84b85f120f45fe6bad63d5e26b5ba4cd89f801
First bad revision: fd69d6b3aeb8e1e04334a0885f60966883a69c08
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f84b85f120f45fe6bad63d5e26b5ba4cd89f801&tochange=fd69d6b3aeb8e1e04334a0885f60966883a69c08

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Comment 3

[:Gijs (he/him)]

I think this is the same problem as the issue with the : in https://bugzilla.mozilla.org/show_bug.cgi?id=1803089#c16 , but this is more serious. What can we do to fix this?

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Screenshot of the dialog on macOS, with filename tooltip showing

Interestingly, if I hover over the filename in the dialog, the tooltip that appears shows it with the proper ordering, as seen here.

Comment 5

[:Gijs (he/him)]

(In reply to Jonathan Kew [:jfkthame] from comment #4)

Interestingly, if I hover over the filename in the dialog, the tooltip that appears shows it with the proper ordering, as seen here.

I haven't verified but I think this is because in bug 1799460 crop=left/start was changed to be implemented by using inverted directionality on the text. That would only apply to that text, not the tooltip.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1814696 - Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

This should do?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1814696 - Standardize on crop="start/end" rather than supporting that and left/right. r=Gijs

Also cleanup a bit the CSS while at it.

Depends on D168788

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1814696 - Remove unused idl properties too. r=Gijs

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1acfd4dbbdae
Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5cadf7b100d
Standardize on crop="start/end" rather than supporting that and left/right. r=Gijs,settings-reviewers,application-update-reviewers,bytesized
https://hg.mozilla.org/integration/autoland/rev/4d2e6730e58f
Remove unused idl properties too. r=Gijs

Comment 11

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/1acfd4dbbdae
https://hg.mozilla.org/mozilla-central/rev/d5cadf7b100d
https://hg.mozilla.org/mozilla-central/rev/4d2e6730e58f

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox110 to wontfix.

For more information, please visit auto_nag documentation.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9315819 [details]
Bug 1814696 - Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively well-targeted patch. The other two patches in the stack are unnecessary-to-uplift cleanup.
• String changes made/needed: none
• Is Android affected?: No

Comment 15

[:Gijs (he/him)]

Comment on attachment 9315819 [details]
Bug 1814696 - Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

We're in RC week - see earlier beta request.

Comment 16

[Negritas Sergiu, Desktop QA]

Hello! I have managed to reproduce the issue with firefox 110.0b9 and 111.0a1(2023-02-02) on macOS 12.6.2. I can confirm that the issue is fixed with firefox 111.0a1(2023-02-08), updating the flags accordingly.

Comment 17

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9315819 [details]
Bug 1814696 - Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

We already built and shipped our Release Candidate and have no driver for a RC2. We can evaluate it for the planned dot release, thanks.

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9315819 [details]
Bug 1814696 - Hint directionality of label content for crop="start" labels. r=Gijs,jfkthame

Low risk, no regression reported since it landed, 2 bug reports by end-user, uplift approved for 110.0.1, thanks.

Comment 19

[Pascal Chevrel:pascalc (PTO until April 26)]

https://hg.mozilla.org/releases/mozilla-release/rev/9abea20ee697

Comment 20

[Monica Chiorean]

Reproduced the issue on Win10x64 using FF 109.0.
Verified as fixed on Win10x64, Mac 10.13 and Ubuntu 20.04 using FF build 110.0.1(20230227191043).

Also added TCs for this scenario : https://testrail.stage.mozaws.net/index.php?/cases/view/2091302