Closed
Bug 662520
Opened 13 years ago
Closed 13 years ago
NewTab popup indicator 'arrow' is missing or is pointed to the right instead of left
Categories
(Firefox for Android Graveyard :: General, defect, P3)
Tracking
(fennec-)
VERIFIED
FIXED
Firefox 8
Tracking | Status | |
---|---|---|
fennec | - | --- |
People
(Reporter: xti, Assigned: lucasr)
References
Details
(Whiteboard: [fennec 5.0b4])
Attachments
(2 files, 1 obsolete file)
33.18 KB,
image/png
|
Details | |
8.54 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
Build id : Mozilla/5.0 (Android;Linux armv7l;rv:7.0a1)Gecko/20110607 Firefox/7.0a1 Fennec/7.0a1 Device: Motorola Droid 2 OS: Android 2.2 Steps to reproduce: 1. Open Nightly app 2. Go to http://popuptest.com/popuptest1.html 3. Tap on Always Show button from the Notification Bar 4. Reload the page opened at step 2 Expected result: A popup toaster is displayed on the middle-left edge of the screen. Its arrow is pointed to the left. Actual result: The toaster arrow is missing or it's pointed to the right. Note: Please see the following video: http://www.youtube.com/user/qaioana#p/a/u/0/IjWBASqaec0
Reporter | ||
Updated•13 years ago
|
Whiteboard: [fennec 5.0b4]
Comment 1•13 years ago
|
||
The 'newtab' popup is not a toaster, so I edited the title. it seems like the arrowbox is being positioned slightly offscreen, which is causing the arrow calculation to mess up positioning the arrow.
Summary: Popup toaster indicator is missing or is pointed to the right instead of left → NewTab popup indicator 'arrow' is missing or is pointed to the right instead of left
Comment 2•13 years ago
|
||
This works fine for me as expected (in Portrait view) using the same build on the N1. Landscape view I see the described behaviour.
Updated•13 years ago
|
Priority: -- → P3
Updated•13 years ago
|
tracking-fennec: --- → ?
Updated•13 years ago
|
Assignee: nobody → lucasr.at.mozilla
tracking-fennec: ? → -
Assignee | ||
Comment 3•13 years ago
|
||
The problem here is that when the new tab overflows the tab scrollbox, the calculation of the arrow direction gets confused because it uses getBoundingClientRect() on the anchorNode which doesn't discard the overflown area of the tab. I introduce two new methods to arrowbox: pointLeftTo() and pointRightTo() which will simply force the arrow direction and set the position according to a certain node. Those methods don't anchor the arrow to the target node as we're forcing direction (anchoring would be pointless). A code refactoring to allow anchorTo, pointLeftTo, and pointRightTo to share same code was necessary.
Attachment #549546 -
Flags: review?(mark.finkle)
Assignee | ||
Comment 4•13 years ago
|
||
Also fixes a type and renames method to pointLeftAt and pointRightAt which makes more sense English-wise.
Attachment #549546 -
Attachment is obsolete: true
Attachment #549546 -
Flags: review?(mark.finkle)
Attachment #549856 -
Flags: review?(mark.finkle)
Updated•13 years ago
|
Attachment #549856 -
Flags: review?(mark.finkle) → review+
Assignee | ||
Updated•13 years ago
|
Keywords: checkin-needed
Comment 5•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/f1a3fea305ff
Keywords: checkin-needed
Comment 6•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/f1a3fea305ff
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 8
Comment 7•13 years ago
|
||
Verified Fixed Mozilla/5.0 (Android; Linux armv7l; rv:8.0a1) Gecko/20110810 Firefox/8.0a1 Fennec/8.0a1
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•