Closed Bug 1210328 Opened 9 years ago Closed 8 years ago

The arrow icon for doorhanger panels is incorrectly placed while the browser is in full screen

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla52
Iteration:
52.2 - Oct 17
Tracking Status
firefox44 --- affected
firefox52 --- verified

People

(Reporter: phorea, Assigned: enndeakin)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files, 1 obsolete file)

Attached image step3 anchor.png
Reproduced with Firefox 42 beta 2, Dev Ed 43.0a2 and Nightly 44.0a1 2015-09-30 under Win 7 32-bit and Ubuntu 14.04 32-bit.
Not reproducible under Mac OS X 10.9.5.

STR: 
1. Open a private window and select "See how this works" to enter tracking protection tour
2. Enter Full screen (F11)
3. Go to step 3 and check the panel

ER: The arrow is correctly placed while in full screen

AR: The arrow is shown on the bottom of the panel
Could be related to bug 1207536.
Whiteboard: [fxprivacy] → [fxprivacy] [triage]
See Also: → 1188400, 1207536
(In reply to Petruta Rasa [QA] [:petruta] from comment #0)
> Created attachment 8668335 [details]
> step3 anchor.png
> 
> Reproduced with Firefox 42 beta 2, Dev Ed 43.0a2 and Nightly 44.0a1
> 2015-09-30 under Win 7 32-bit and Ubuntu 14.04 32-bit.
> Not reproducible under Mac OS X 10.9.5.
> 
> STR: 
> 1. Open a private window and select "See how this works" to enter tracking
> protection tour
> 2. Enter Full screen (F11)
> 3. Go to step 3 and check the panel
> 
> ER: The arrow is correctly placed while in full screen
> 
> AR: The arrow is shown on the bottom of the panel
> Could be related to bug 1207536.

Does this only happen in the Control Center during the UI Tour, or can you reproduce it when manually opening the Control Center?
Flags: needinfo?(petruta.rasa)
I could only see it during the tour.
Flags: needinfo?(petruta.rasa)
Summary: The arrow icon of the tracking protection panel is incorrectly placed while the TP tour is in full screen → The arrow icon for doorhanger panels is incorrectly placed while the browser is in full screen
(In reply to Brian Grinstead [:bgrins] from comment #1)
> Does this only happen in the Control Center during the UI Tour, or can you
> reproduce it when manually opening the Control Center?

Actually, I could reproduce it on other pages too. Apparently the doorhanger must be activated from page content while the browser is full screen.
Other samples:
- http://mozilla.github.io/webrtc-landing/gum_test.html select any of the "Video", "Audio" or "Audio & Video" options
http://webaudioplayground.appspot.com/#/ choose "Live input" option
Whiteboard: [fxprivacy] [triage]
Depends on: 1206133
Attached patch Improve flip calculations (obsolete) — Splinter Review
This patch improves detection of whether a flip was performed, by comparing the result to the original expected direction of the popup, rather than just guessing.

You may need the patch in bug 1206133 for this too in some cases.

Bug 1188400 may be fixed by both patches as well.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Blocks: 1188400
See Also: → 1197446
Neil, is this patch ready for review? What's the next step here?
Flags: needinfo?(enndeakin)
See Also: 1197446
It could be ready, but many cases wouldn't be fixed without bug 1206133, which itself has the problem that it breaks some tests.
Flags: needinfo?(enndeakin)
This version has a minor fix for rtl.
Attachment #8695968 - Attachment is obsolete: true
Attachment #8798038 - Flags: review?(ksteuber)
Comment on attachment 8798038 [details] [diff] [review]
Improve flip calculations, v2

Review of attachment 8798038 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good!

::: layout/xul/nsMenuPopupFrame.cpp
@@ +1542,5 @@
>  
>      // Next, check if there is enough space to show the popup at full size when
>      // positioned at screenPoint. If not, flip the popups to the opposite side
>      // of their anchor point, or resize them as necessary.
> +    

Formatting nit: extra whitespace on line 1546
Attachment #8798038 - Flags: review?(ksteuber) → review+
https://hg.mozilla.org/mozilla-central/rev/a9e9e6a3d720
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Component: Tours → XP Toolkit/Widgets: Menus
Product: Firefox → Core
Target Milestone: Firefox 52 → mozilla52
QA Whiteboard: [good first verify]
Iteration: --- → 52.2 - Oct 17
I have reproduced this bug with Nightly 44.0a1 (2015-10-01) in Elementary OS 64bit 

This bug's fix is now verified in Latest Nightly 52.0a1

Build ID 	20161020030211
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

[testday-20161021]
I have reproduced this bug with Nightly 44.0a1 (2015-10-01) in Windows 10, 64bit .

This bug's fix is now verified in Latest Nightly 52.0a1 (2016-10-20).

Build ID 	20161020030211
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

[testday-20161021]
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: