1396583 - Wrong Tooltip position after searching for "firefox"/"nightly"

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P1)

Description

[Camelia Badau [:cbadau], Desktop Test Engineering]

Attachment: issue.png

[Affected versions]:
- Firefox 57.0a1
- Firefox 56 Beta 8

[Affected platforms]:
- Windows 7 x64
- macOS 10.12.6
- Ubuntu 16.04 x64 

[Steps to reproduce]:
1. Launch Firefox and go to "about:preferences".
2. Search for "firefox"/"nightly"(for Nightly builds).

[Expected result]:
- The position of the Tooltip should be correct.

[Actual result]:
- Wrong Tooltip position after searching for "firefox"/"nightly"(for Nightly builds). Please see attachment "issue.png". 

[Regression range]:
- It is not a regression. This is reproducible since the feature was enabled (2017-06-16).

Comment 1

[Ricky Chien [:rickychien] (inactive)]

Attachment: Bug 1396583 - Fix wrong tooltip position by wrapping hbox

Review commit: https://reviewboard.mozilla.org/r/176262/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/176262/

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8904428 [details]
Bug 1396583 - Fix wrong tooltip position by wrapping hbox

https://reviewboard.mozilla.org/r/176262/#review181950

::: commit-message-1401e:1
(Diff revision 1)
> +Bug 1396583 - Wrong Tooltip position after searching for "firefox"/"nightly" r?jaws

Please change this commit message to describe the fix and why it is necessary, instead of just describing the problem.

Comment 3

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8904428 [details]
Bug 1396583 - Fix wrong tooltip position by wrapping hbox

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/176262/diff/1-2/

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6f185e25c9d7
Fix wrong tooltip position by wrapping hbox r=jaws

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/6f185e25c9d7

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Can you request uplift so we can get this into beta 11 next Monday? Thanks!

Comment 7

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8904428 [details]
Bug 1396583 - Fix wrong tooltip position by wrapping hbox

Approval Request Comment
[Feature/Bug causing the regression]:
[User impact if declined]: minor
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]: see description
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: minor
[Why is the change risky/not risky?]: An edge case issue when searching particular keyword
[String changes made/needed]: no

Comment 8

[Gerry Chang [:gchang]]

Comment on attachment 8904428 [details]
Bug 1396583 - Fix wrong tooltip position by wrapping hbox

UI polish. Beta56+.

Hi Camelia,
Can you help check if this issue was fixed in the latest nightly?

Comment 9

[Camelia Badau [:cbadau], Desktop Test Engineering]

Verified fixed on Windows 7 x64, Ubuntu 16.04 x32 and macOS 10.12 using latest Nightly 57.0a1 (2017-09-10).

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c029dea3522f

Comment 11

[Camelia Badau [:cbadau], Desktop Test Engineering]

I've tested on Windows 7 x64, Ubuntu 14.04 and macOS 10.12 using Firefox 56 Beta 12 (buildID: 20170914024831) and the issue is NOT FIXED here: wrong Tooltip position after searching for "firefox".

Comment 12

[Ricky Chien [:rickychien] (inactive)]

I don't see the code changes in Comment 10 has landed in latest Firefox Beta.

Ryan, how many days we can see the issue get fixed in Firefox Beta?

Comment 13

[Ryan VanderMeulen [:RyanVM]]

As far as I can tell, this fix should have been in Firefox 56b11. And next week is the RC build.

One note - we hit a lot of merge conflicts on other uplifts yesterday due to in-content vs. in-content-new path issues. Comment 10 updated browser/components/preferences/in-content/privacy.xul. Does that need fixing?

(For future reference, waiting another cycle before doing all the in-content removal and in-content-new renaming would have made life easier...)

Comment 14

[Ricky Chien [:rickychien] (inactive)]

> One note - we hit a lot of merge conflicts on other uplifts yesterday due to in-content vs. in-content-new path issues. Comment 10 updated browser/components/preferences/in-content/privacy.xul. Does that need fixing?

Ah, yes! Please update browser/components/preferences/in-content-new/privacy.xul as well.

Sorry for that, we should take care of it next time. Thanks!

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Yes, please double-check that on future uplift requests for things involving the old vs. new prefs. At this point, it's going to miss b12 as well, but I'll get it landed for the RC.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Should I revert the change in comment 10?

Comment 17

[Ricky Chien [:rickychien] (inactive)]

I believe it's unnecessary. Thanks

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e7ef836b14ae (FIREFOX_56b13_RELBRANCH)
https://hg.mozilla.org/releases/mozilla-release/rev/cd6d5cef00aa

Comment 19

[Camelia Badau [:cbadau], Desktop Test Engineering]

Verified fixed on Windows 10 x64, macOS 10.12 and Ubuntu 16.04 x64 using Firefox 56 RC build 3 (buildID: 20170921234614).