Closed Bug 782062 Opened 10 years ago Closed 10 years ago

Form field dropdown Drupal overlay

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
16 Branch
Platform:
x86_64
Windows 8
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla18
Tracking Flags:
Tracking Status
firefox17 + verified
firefox18 + verified

People

(Reporter: akayanni, Assigned: ehsan.akhgari)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Dropdown appearing on second monitor
143.11 KB, image/png
Details
Patch (v2)
1.53 KB, patch
roc
: review+
lsblakk
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120810030512

Steps to reproduce:

Using Drupal 7 in admin mode with the JS overlay on.




Actual results:

Form field dropdown boxes fail or appear on at 2nd screen

Tested in current stable version and OK bad in Minefield

The issue is specific to having the JS overlay active


Expected results:

Normal form dropdown
Can you attach a screenshot of the issue, please?
Are you using 2 monitors?
I'm using 2 monitors. At one point in the cycle the dropdown appear on the second monitor in the current nightly it doesn't appear at all.

There is nothing to see. You need an admin access to Drupal I can do that if you don't have a test bench for Drupal.

The KEY is JS Adnim overlay. That is when the fault shows up. It's been present since the initial release of 17a.
May be related to bug 772837 / bug 781799.
Aleksej, I think like you. Maybe the reporter can try to disable hardware acceleration in advanced options of Firefox and make a test.
gfx.direct2d.force-enabled;true
gfx.direct2d.disabled;false

If you mean reversing those setting that's not it. This looks more like an error in the JS engine.
Or just uncheck HWA in "Options > Advanced > General > Use hardware acceleration when available", then restart Firefox.
Tested, that's not it.
A testcase would be great here.

Seems you're using Windows8. Did this occur with previous Windows versions or Firefox versions?
Component: Untriaged → Layout
Keywords: testcase-wanted
Product: Firefox → Core
Yep tested with the current release version and no issue exists. Only see it in Minefield.
Here use this old Uni assignment

http://www.imagonullius.com/faceit/brief

User: firefox
Password: firefox

Hit Edit

Go to the dropdown

 Text format [Drop down]

    Web page addresses and e-mail addresses turn into links automatically.

Remember as I've said it only happens then the JS overlay is active.
Hardware: x86 → x86_64
I'm able to reproduce the regression with the website you linked.
A drop-down list can be open when the user click on it. Only the default value is displayed.
And it happens on a single monitor.

The regression is in Aurora too.

m-c
good=2012-06-06
bad=2012-06-07
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6338a8988917&tochange=7e4c2abb9fc9

Bisecting is needed to find the suspected bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: 17 Branch → 16 Branch
Correction: A drop-down list CANNOT be open when the user click on it. (sorry)
Great, surprised it got as far as Aurora. I'll leave the user and password active until this is resolved or you have an alternative Drupal test bench.
For the record I don't remember the issue being active in Minefield 16. I could be wrong but it seemed to be introduced after 17. If that help track it down in the change log.
(In reply to Yani from comment #14)
> For the record I don't remember the issue being active in Minefield 16. I
> could be wrong but it seemed to be introduced after 17. If that help track
> it down in the change log.
Minefield doesn't exist anymore (release<beta<aurora(a2)<nightly(a1)). ;)
I tried with Aurora and the bug is present (like in Nightly).
I just notice this effect with the latest nightly. It's the dropdown appearing on the second monitor. Looks like the issue with the drupal overlay then has an odd interaction with other JS dropdowns.

You will see in the image.
Bisecting on mac gives me this:

The first bad revision is:
changeset: 95903:df6702c41ddd 
user: Ehsan Akhgari <ehsan@mozilla.com> 
date: Wed Jun 06 00:53:48 2012 -0400 
summary: Bug 157681 - Part 2: Optimize positioned frame offset changes by moving the frame as opposed to reflowing it in case we know that the size of the frame will not change; r=dbaron

Doesn't occur on Ubuntu, but Mac and Windows are affected. As a workaround: resizing the window makes the form selectable.
Keywords: testcase-wanted
Blocks: 157681
This is caused because the iframe containing the document is moved, and the view position gets out of sync.  We should just avoid the optimization in bug 157681 for iframes.  I have a patch which fixes this.
Attached patch Patch (v1) (obsolete) — — Splinter Review
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #655690 - Flags: review?(roc)
Do we need this fix for any frame which can have a view? If so we'll need to at least handle object frames.
(In reply to comment #20)
> Do we need this fix for any frame which can have a view? If so we'll need to at
> least handle object frames.

Yes, we do.  Is there a better way to check for that than the frame type?
frame->HasView() will tell you if the frame has a view. Does that handle what you need?
(In reply to comment #22)
> frame->HasView() will tell you if the frame has a view. Does that handle what
> you need?

I think so.  I'll try that.
Attached patch Patch (v2) — — Splinter Review 
Check for views instead
Attachment #655690 - Attachment is obsolete: true
Attachment #655690 - Flags: review?(roc)
Attachment #655736 - Flags: review?(roc)
Comment on attachment 655736 [details] [diff] [review]
Patch (v2)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 157681
User impact if declined: regression in comment 0
Testing completed (on m-c, etc.): local testing
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none
Attachment #655736 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/a9858d2ad58b
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Checked here is perfect, thank you.
(In reply to Yani from comment #29)
> Checked here is perfect, thank you.

Yani, could you keep the guest account alive until someone from Mozilla QA resolves this bug as VERIFIED, please?
No problem
Attachment #655736 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
@Lukas: just for my information, is it normal that no flag has been set about this regression?
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0

Verified on Firefox 17 beta 3 that the form field dropdown is properly displayed - used the STR from Comment 10 on Windows 8 dual monitors and Mac OS X with a single monitor.
status-firefox17: fixed → verified
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/18.0 Firefox/18.0

Verified as fixed on Firefox 18 beta 1 - the form field dropdown is properly displayed (verified using the STR from Comment 10 on Windows 8 dual monitor and on Mac OS X single monitor).
status-firefox18: fixed → verified
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.