Open Bug 628020 Opened 9 years ago Updated 9 years ago

Invalid input arrow panel doesn't move when the page is scrolled

Categories

(Toolkit :: XUL Widgets, defect)

x86
Windows 7
defect
Not set

Tracking

()

People

(Reporter: jk1700, Unassigned)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre
Build Identifier: 

When a form displays arrow panel for invalid input and the page scrolled (using mouse wheel) the arrow panel doesn't move (sometimes it moves after few seconds)

Reproducible: Always

Steps to Reproduce:
1. Open the testcase
2. Submit form
3. Scroll page using the mouse wheel
Actual Results:  
Input field moves up/down but the arrow panels stays in a place

Expected Results:  
Arrow panel should move in the same direction as input
Attached file testcase
Version: unspecified → Trunk
Blocks: 616607
It's easy enough to make the popup close when the page is scrolled. I think we'll need to make nsXULPopupManager::ShouldRollupOnMouseWheelEvent check a custom attribute after all.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #3)
> It's easy enough to make the popup close when the page is scrolled. I think
> we'll need to make nsXULPopupManager::ShouldRollupOnMouseWheelEvent check a
> custom attribute after all.

Wouldn't be better to have the popup stay where it should be? or really too hard?
Might be. It isn't easier though.

Closing the popup makes more sense to me.
Whatever solution you'll choose maybe it's worth also do the same also for page zoom event (open testcase, submit form, press Ctrl--, the panel position doesn't change), not only mouse wheel?
The element could move in many different ways, for instance, a script could hide it or move the anchor element somewhere else on the page. We can't really handle all possibilities, but basic scrolling in simple. If there is currently an event or notification for when the zoom changes, we could do that as well, but it's certainly an edge case.
I don't know what would be the impact in performance but could we check the anchor position at each MozBeforePaint?
You need to log in before you can comment on or make changes to this bug.