Closed
Bug 616607
Opened 14 years ago
Closed 14 years ago
Arrow panels have sometimes a wrong position
Categories
(Firefox :: General, defect)
Firefox
General
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
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
Comment 5•14 years ago
|
||
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/
Comment 6•14 years ago
|
||
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.
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
Comment 10•14 years ago
|
||
(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
Comment 11•14 years ago
|
||
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
Comment 12•14 years ago
|
||
(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).
Reporter | ||
Comment 13•14 years ago
|
||
(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
Reporter | ||
Comment 14•14 years ago
|
||
Updated•14 years ago
|
blocking2.0: ? → final+
Assignee | ||
Comment 15•14 years ago
|
||
Seems to be fixed by the patch in bug 616502.
Comment 16•14 years ago
|
||
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]
Assignee | ||
Comment 17•14 years ago
|
||
Attachment #500245 -
Flags: review?(gavin.sharp)
Comment 18•14 years ago
|
||
I think Neil Rashbrook would probably be a better reviewer for this. Looks like there's a stray "/*" addition in the test?
Assignee | ||
Comment 19•14 years ago
|
||
Attachment #500245 -
Attachment is obsolete: true
Attachment #500295 -
Flags: review?(neil)
Attachment #500245 -
Flags: review?(gavin.sharp)
Updated•14 years ago
|
Comment 20•14 years ago
|
||
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+
Updated•14 years ago
|
Whiteboard: [will be fixed by bug 616502] → [needs landing]
Updated•14 years ago
|
Whiteboard: [needs landing] → [needs landing][hardblocker]
Assignee | ||
Comment 21•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Comment 22•14 years ago
|
||
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?
Updated•14 years ago
|
Whiteboard: [needs landing][hardblocker] → [hardblocker]
Target Milestone: --- → Firefox 4.0b10
Comment 23•14 years ago
|
||
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.
Comment 24•14 years ago
|
||
Comment 25•14 years ago
|
||
Assignee | ||
Comment 26•14 years ago
|
||
Please file separate bugs on specific issues with testcases.
Comment 27•14 years ago
|
||
Creating two new bugs will represent only duplicates for this one that should be reopened.
Reporter | ||
Comment 28•14 years ago
|
||
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.
Comment 29•14 years ago
|
||
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.
Comment 30•14 years ago
|
||
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
Comment 31•14 years ago
|
||
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.
Description
•