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

VERIFIED FIXED in Firefox 56

Status

()

P1
normal
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: cbadau, Assigned: rickychien)

Tracking

(Blocks: 1 bug)

56 Branch
Firefox 57
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55 unaffected, firefox56+ verified, firefox57 verified)

Details

(Whiteboard: [photon-preference])

Attachments

(2 attachments)

Posted image 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).
Whiteboard: [photon-preference][triage]
Assignee: nobody → rchien
Status: NEW → ASSIGNED
Flags: qe-verify+
Priority: -- → P1
QA Contact: hani.yacoub
Comment hidden (mozreview-request)
Whiteboard: [photon-preference][triage] → [photon-preference]
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.
Attachment #8904428 - Flags: review?(jaws) → review+
Comment hidden (mozreview-request)

Comment 4

2 years ago
Pushed by rchien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6f185e25c9d7
Fix wrong tooltip position by wrapping hbox r=jaws
https://hg.mozilla.org/mozilla-central/rev/6f185e25c9d7
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox57: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Can you request uplift so we can get this into beta 11 next Monday? Thanks!
tracking-firefox56: --- → +
Flags: needinfo?(rchien)
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
Flags: needinfo?(rchien)
Attachment #8904428 - Flags: approval-mozilla-beta?
status-firefox-esr52: --- → unaffected
Version: Trunk → 56 Branch
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?
Flags: needinfo?(camelia.badau)
Attachment #8904428 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Verified fixed on Windows 7 x64, Ubuntu 16.04 x32 and macOS 10.12 using latest Nightly 57.0a1 (2017-09-10).
status-firefox57: fixed → verified
Flags: needinfo?(camelia.badau)

Comment 10

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/c029dea3522f
status-firefox56: affected → fixed
Whiteboard: [photon-preference] → [photon-preference]
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".
Flags: needinfo?(rchien)
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?
Flags: needinfo?(rchien) → needinfo?(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...)
Flags: needinfo?(ryanvm) → needinfo?(rchien)
> 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!
Flags: needinfo?(rchien)
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.
Should I revert the change in comment 10?
Flags: needinfo?(rchien)
I believe it's unnecessary. Thanks
Flags: needinfo?(rchien)
status-firefox56: fixed → affected
Flags: needinfo?(ryanvm)
Flags: needinfo?(ryanvm)
Verified fixed on Windows 10 x64, macOS 10.12 and Ubuntu 16.04 x64 using Firefox 56 RC build 3 (buildID: 20170921234614).
Status: RESOLVED → VERIFIED
status-firefox56: fixed → verified
You need to log in before you can comment on or make changes to this bug.