User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:25.0) Gecko/20130727 Firefox/25.0 (Nightly/Aurora) Build ID: 20130727030206 Steps to reproduce: Using a mouse, right-click on a hyperlink and you get a set of options. Actual results: The options are offset with a wide 'white space' from the end margin to where the name of the option starts (see attached example). This doesn't seem to affect drop down forms all the time (such as select a country). I have seen issues with the drop-down arrow in these forms however (see https://pkiwidgets.quovadisglobal.com/pkiwidgets/generateCSR.aspx for instance). Expected results: The option names should be closer to the margin.
Summary: Right-click drop down options are offset → Defect - Right-click drop down options are offset
Whiteboard: feature=defect c=tbd u=tbd p=0
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=0 [preview-triage]
Whiteboard: feature=defect c=tbd u=tbd p=0 [preview-triage] → feature=defect c=tbd u=tbd p=0
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect u=metro_firefox_user c=context_menus p=0
Summary: Defect - Right-click drop down options are offset → [MP] Defect - Right-click drop down options are offset
Whiteboard: feature=defect u=metro_firefox_user c=context_menus p=0 → [preview] feature=defect u=metro_firefox_user c=context_menus p=0
Assignee: nobody → rsilveira
Status: NEW → ASSIGNED
Whiteboard: [preview] feature=defect u=metro_firefox_user c=context_menus p=0 → [preview] feature=defect u=metro_firefox_user c=context_menus p=2
Can't seem to reproduce anymore, tried on X1 carbon and surface pro. Resolving for now, reopen if happens again.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 Build ID: 20130827030201 WFM Tested on both Windows 8 32bit and 64bit using latest Nightly for iteration #13, and it seems to me that the problem is still reproducible, as shown in the attached screenshots. (screenshot2 will be attached in the next comment) Does anyone have any suggestions/thoughts?
Reopening as Manuela was able to reproduce. I still can't see it on my box. Manuela, was it on a HiDPI device? Windows 8.1?
Assignee: rsilveira → nobody
Status: RESOLVED → REOPENED
Flags: needinfo?(rsilveira) → needinfo?(manuela.muntean)
Resolution: WORKSFORME → ---
Manuela, please file a follow up defect if this can be reproduced as per Rodrigo's Comment #4.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → FIXED
(In reply to Rodrigo Silveira [:rsilveira] from comment #4) > Reopening as Manuela was able to reproduce. I still can't see it on my box. > > Manuela, was it on a HiDPI device? Windows 8.1? Unfortunatelly, I don't have a HiDPI device to test with. I can also reproduce the issue with Windows 8.1 32-bit. I have logged bug 918225 for this, as suggested in comment 5.
While testing this for iteration #16, with latest Nightly (build ID: 20131024030204) on Win 8 32-bit, I can see the behavior attached in this comment. Is this the expected behavior?
Yes, this is the expected behavior after bug 918225. Thanks!
Marking this verified, since it works now, based on comment 7, comment 8 and comment 9. Also verified during iteration #17, with latest Nightly (build ID: 20131028030205) on both Win 8 32-bit and 64-bit. I get the same behavior as shown here: https://bugzilla.mozilla.org/attachment.cgi?id=822330
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.