Closed Bug 616607 Opened 9 years ago Closed 9 years ago

Arrow panels have sometimes a wrong position

Categories

(Firefox :: General, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 4.0b10
Tracking Status
blocking2.0 --- final+

People

(Reporter: jk1700, Assigned: enndeakin)

References

(Depends on 2 open bugs)

Details

(Keywords: testcase, Whiteboard: [hardblocker][fx4-fixed-bugday])

Attachments

(9 files, 1 obsolete file)

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

When input in at the bottom of the page the arrow panels displays above the input but arrow is on top instead of bottom

Reproducible: Always

Steps to Reproduce:
1. Open the test case
2. Press "End" to scroll to the bottom
3. Submit the form
Actual Results:  
Arrow panel is displayed above the input but the arrow is on the top

Expected Results:  
Arrow should be at the bottom of the arrow panel
Attached file Testcase
Attached image Screenshot
Blocks: 595432
Version: unspecified → Trunk
I've just found that the problem appears when there is not enough space on the screen to display the panel (not in the browser window!), so it's best to run the testcase in full screen mode. Bug exists also on win XP

Moreover, when there is enough space on the screen but there is a task bar on the bottom the arrow panel hides behind the task bar

I guess it should block bug 554937
Blocks: 554937
Even when the popup does have enough room, it does not seem to be appropriately placed (on Fx 4 nightly, on Mac OS X). See the screenshot in my blog post:
http://fredericiana.com/2010/12/14/better-web-forms-with-html5-and-firefox-4/
Gadjo, can you check again? It might have been fixed by bug 606343.

Fred, could you open another bug for your issue, it's not the same issue.
It's not fixed, issues from both my screenshots still exist
Attached image After fixing bug 606343
Another issues which may be related to this one (open the URL and press enter):

1) data:text/html,<!DOCTYPE html><form style="float: right"><input autofocus required style="width: 5em"></form>

Arrow first appears on the right side for a very short moment (sometimes barely visible), then moves to the left side, but it doesn't touch to the input

2) data:text/html,<form style="float: right"><input autofocus required style="width: 5em"></form>

Arrow first appears on the left side for a very short moment, then moves to the right side
(In reply to comment #9)
> Another issues which may be related to this one (open the URL and press enter):
> 
> 1) data:text/html,<!DOCTYPE html><form style="float: right"><input autofocus
> required style="width: 5em"></form>
> 
> Arrow first appears on the right side for a very short moment (sometimes barely
> visible), then moves to the left side, but it doesn't touch to the input
> 
> 2) data:text/html,<form style="float: right"><input autofocus required
> style="width: 5em"></form>
> 
> Arrow first appears on the left side for a very short moment, then moves to the
> right side

You two examples seem to be the same but I can confirm it doesn't work as expected.
Status: UNCONFIRMED → NEW
Ever confirmed: true
So, the arrow panels for some reasons do not show point to the correct thing sometimes because it's not positioned correctly. It's visible now because arrow panels are now used to show the error message when the user tries to submit an invalid form.

I guess it should block given that it's a bug in a new feature (arrow panel)
which has direct consequence for another new feature (HTML5 Forms validation).
The bug isn't critical though.
blocking2.0: --- → ?
Keywords: testcase
OS: Windows 7 → All
Hardware: x86 → All
Summary: Wrong position of an arrow in invalid form popup → Arrow panels have sometimes a wrong position
(In reply to comment #5)
> Even when the popup does have enough room, it does not seem to be appropriately
> placed (on Fx 4 nightly, on Mac OS X). See the screenshot in my blog post:
> http://fredericiana.com/2010/12/14/better-web-forms-with-html5-and-firefox-4/

I've open bug 619223 (you are in the CC list).
(In reply to comment #10)
> You two examples seem to be the same but I can confirm it doesn't work as
> expected.

They are not the same, they show that the position of arrow depends on DOCTYPE (first example with doctype has an arrow on the left, the second one without doctype has an arrow on the right), see the attached screenshot
blocking2.0: ? → final+
Seems to be fixed by the patch in bug 616502.
Indeed, this should be fixed by bug 616502.
I'm assigning this bug to you Neil just to make sure it's clear you are working on this bug via bug 616502.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Whiteboard: [will be fixed by bug 616502]
Attachment #500245 - Flags: review?(gavin.sharp)
Blocks: 616502
I think Neil Rashbrook would probably be a better reviewer for this. Looks like there's a stray "/*" addition in the test?
Attachment #500245 - Attachment is obsolete: true
Attachment #500295 - Flags: review?(neil)
Attachment #500245 - Flags: review?(gavin.sharp)
No longer blocks: 616502
Depends on: 616502
Comment on attachment 500295 [details] [diff] [review]
updated patch: remove stray comment

When I tried the testcase with the textbox close to the bottom of the screen, the arrow popup decided to flip itself after setting itself up to be a up arrow; subsequently it displayed the correct direction. The magic figure seems to be around 50-65 pixels on my system, which corresponds to the panel increasing in size by 16 pixels to accommodate the arrow which appears asynchronously.
Attachment #500295 - Flags: review?(neil) → review+
Whiteboard: [will be fixed by bug 616502] → [needs landing]
Whiteboard: [needs landing] → [needs landing][hardblocker]
http://hg.mozilla.org/mozilla-central/rev/f13474da3875
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Blocks: 616502
No longer depends on: 616502
On Windows 7, with the browser set to fullscreen and add-on bar enabled; The browser seems to always display the popup below which is behind the taskbar in this case.

Should a separate bug be filed?
Whiteboard: [needs landing][hardblocker] → [hardblocker]
Target Milestone: --- → Firefox 4.0b10
Depends on: 626563
Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

Using https://bug616607.bugzilla.mozilla.org/attachment.cgi?id=495108 issue was still present (See Screenshot C22_1 and Screenshot C22_2).

Screenshot C22_1:
 - when in fullscreen the arrow panel is not displayed fully (in the picture the left part of the panel is missing)

Screenshot C22_2:
 - when Firefox is not maximized, the arrow panel is put behind the windows taskbar.
Attached image Screenshot C22_1
Attached image Screenshot C22_2
Please file separate bugs on specific issues with testcases.
Creating two new bugs will represent only duplicates for this one that should be reopened.
Actually the original bug here was "Wrong position of an arrow in invalid form popup", the title has been changed but still it's about an arrow - see the second attachment.
Your bugs refer to clipping the panel itself, so they are different issues and deserve a new bug.
George, please file separate bugs from comment #23. I thin this is really about the arrows the notifications point to, whereas the issues you found are about the notification clipping.
Logged two new bugs for each of the issues:

Bug 627972 - Arrow panel clipping when in maximized mode

Bug 627974 - Arrow panel hidden behind Windows taskbar when browser not maximized
Depends on: 628238
Depends on: 628020
Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.