Closed Bug 230267 Opened 21 years ago Closed 21 years ago

BeOS: The caret is stuck or hidden (when GIF animations are visible)

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
BeOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugzillamozilla, Assigned: sergei_d)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

Patch (diff -up)
856 bytes, patch
thesuckiestemail
: review+
Details | Diff | Splinter Review
InvertRect, better comment
834 bytes, patch
sergei_d
: review+
dbaron
: approval1.7b+
Details | Diff | Splinter Review 
Steps to reproduce:
1. Open www.bebits.com (the problem occurs on other websites as well)
2. Type a string in the Search field at the upper right corner of the page.
3. Using the left arrow or the mouse, try to place the caret in the middle of
the typed string.

Result: 
The caret stops blinking and stays at the end of the string.

Expected result: 
The caret should be displayed where ever the user places it
(within the textbox)

Workaround: 
Disable GIF animation. Preferences -> Privacy & Security -> Images -> Animated
images should loop -> Never

Prog.
Tweaking the summary a bit...

Prog.
Summary: BeOS: When GIF animations are visible, caret is stuck or hidden → BeOS: The caret is stuck or hidden (when GIF animations are visible)
This issue turns text fields almost unusable. So increasing severity
Best workaround at moment i found is to set short caret blink time in
nsLookAndFeel.cpp.

100 or less
Severity: normal → major
Attached patch Patch (diff -up) — — Splinter Review 
Sets caret blink time to 100 in nsLookAndFeel.cpp

There are other problems with caret appearance too, but that's different story
Comment on attachment 139110 [details] [diff] [review]
Patch (diff -up)

review request
Attachment #139110 - Flags: review?(timeless)
Comment on attachment 139110 [details] [diff] [review]
Patch (diff -up)

asking Decaf to review simplest patch.
(timeless seems being really busy)
Attachment #139110 - Flags: review?(timeless) → review?(thesuckiestemail)
Comment on attachment 139110 [details] [diff] [review]
Patch (diff -up)

r=thesuckiestemail@yahoo.se
Attachment #139110 - Flags: review?(thesuckiestemail) → review+
checked in
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
It seems that InvertRect don't take in account of clipping region on Windows,
yet all other drawing does. Probably that is the reason why Mozilla don't set it
generally, but it is required in BeOS. Adding clipping in ::InvertRect method on
BeOS fixes bug.
Simon has fix which was tested for quite long and works well, hope we submit
patch very soon
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This forces the clipping region to be set to the caret when it is drawn.

The sync is needed to ensure the caret is drawn instantly - ensures correct
behaviour on key presses.

Now BeOS caret behaviour seems to match that in windows.
How about backing out the original patch? we could probably return to the
standard blink rate, right?

Prog.
There are some other changes I'd like to make in nsLookAndFeel - put the blink
time back to 300, reduce the submenu delay, and make the text caret on
multi-line text fields be 1 pixel.

I was thinking of doing this all in one patch.
2 Simon
Yeah, it is beter to made changes in nsLookAndFeel at once.

But i wish to warn you about your idea to voluntary cahnge color settings.

nsAppLookAndFeel idea is to put mozilla follow OS settings dynamically, and for
me, at least under R5 those colors now looks quite snappy, using definitions
from BeOS headers. Though, some changes may be made taking Dano in account, it
has 1)wider choice of UI settings 2)Those settings are available to user via
Preferences. So, under PhOS with Loon's default choices it definitely needs some
adjustment. Dunno about Zeta, though - but nobody complained yet.
Comment on attachment 143587 [details] [diff] [review]
Fix InvertRect clipping patch (diff -up)

Review Request
Attachment #143587 - Flags: review?(sergei_d)
I agree that most of the colors are correct on BeOS.

The purple used for selections is slightly strange though - I've never seen 
that used by any other app under BeOS.
Color discussion is sure off-topic here, but i've to mentioned, that on my
machine text selection color is dark blue-grey and menu item selection color -
bright-deep blue. Under R5. But under PhOS it is really purple, awful and
unaesthetical - why i mentioned need to check it again for Dani API.
Comment on attachment 143587 [details] [diff] [review]
Fix InvertRect clipping patch (diff -up)

r=sergei_d@fi.tartu.ee
Attachment #143587 - Flags: review?(sergei_d) → review+
Improve the readability of the explanatory comment.
Attachment #143587 - Attachment is obsolete: true
Comment on attachment 143715 [details] [diff] [review]
InvertRect, better comment

Review request for small change to comment
Attachment #143715 - Flags: review?(sergei_d)
Comment on attachment 143715 [details] [diff] [review]
InvertRect, better comment

r=sergei_d@fi.tartu.ee

Don't forget about approval request, if you wish to check it in before	1.7b
"release"
Attachment #143715 - Flags: review?(sergei_d) → review+
Comment on attachment 143715 [details] [diff] [review]
InvertRect, better comment

Request approval for 1.7b 

Patch reviewed, no need for superreview (port-only code in port-specific
folder)
Attachment #143715 - Flags: approval1.7b?
Attachment #143715 - Flags: approval1.7b? → approval1.7b+
Patch checked in.
marking as fixed
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: