Bug 248137 – PrettyPrint does not show exact output as "Actual"

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Tools / Tests

[Ahmad Saleem]

Hi Team,

Either it is a bug or intended case but I noticed while trying to fix bug 123163 for these tests:

accessibility/mac/select-text/select-text-7.html
accessibility/mac/select-text/select-text-8.html
accessibility/mac/select-text/select-text-9.html
accessibility/mac/select-text/select-text-135575.html

Failure Link - https://ews-build.s3-us-west-2.amazonaws.com/macOS-BigSur-Release-WK2-Tests-EWS/1a60b3fd-21572/results.html

If we look into actual from above as an example (select-text-135575.html):

Line 3 - TEXT2: THEÂ quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

Pretty Print - TEXT2: THE quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

When I change to "Actual", I also get same failure while trying to copy from "Result" then same back again.

Right now, I am adding - meta tag with utf-8 to see, if this fixes issue but I think "Pretty Print" should show same as "Actual" as well.

Appreciate if something like this can be made consistent.

Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/102685877>

[Ahmad Saleem]

Can this be escalated because this is causing issue in other Editing test cases as well:

https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/aa512722-169005/results.html

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #2)
> Can this be escalated because this is causing issue in other Editing test
> cases as well:
> 
> https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/aa512722-169005/
> results.html

More precisely in insert-space.html:

https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/aa512722-169005/editing/inserting/insert-space-pretty-diff.html

Actual show this:

expected <div contenteditable>Â  Â | </div>,

While PrettyPrint show  as "space", which is causing all mayhem when trying to understand what is this issue.

[Alexey Proskuryakov]

Could you please clarify what the issue is? https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/aa512722-169005/editing/inserting/insert-space-pretty-diff.html looks like what I'd expect to me. And the pretty diff page already has <meta charset='utf-8'>.

[Ahmad Saleem]

(In reply to Alexey Proskuryakov from comment #4)
> Could you please clarify what the issue is?
> https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/aa512722-169005/
> editing/inserting/insert-space-pretty-diff.html looks like what I'd expect
> to me. And the pretty diff page already has <meta charset='utf-8'>.

My issue is that in pretty print, it show it as 'space' (might be due to UTF-8) and if you put space to change expectation, it is wrong because it is different character like  and fail again in the next run.

So my "space" fails since it does not match "Actual". Should I change my expectation file, which is already in UTF-8 to UTF-8 BOM or other?

Or we can fix it to show some message that PrettyPrint is in UTF-8 and refer to Actual to see correct output but change any HTML entities to UTF-8 or accordingly.

[Alexey Proskuryakov]

Copy/pasting spaces from HTML generally isn't going to be exact. And there are many other cases where content would be transformed, such as different Unicode normalizations, newlines, other invisible characters.

In this particular case, these are all spaces, just different ones (regular vs. non-breaking space U+00A0).

The usual workflow for updating expectations is downloading actual results file, and saving it as -expected.txt, not manually editing file based on pretty diff.

[Ahmad Saleem]

It was me being stupid and downloading 'Actual' file and then using to do rebaselining is correct way.

Marking this 'RESOLVED WORKSFORME'. Thanks!