Closed
Bug 309099
Opened 18 years ago
Closed 18 years ago
Entire screen is repainted each time focus moves
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: roc)
References
Details
(Keywords: access, fixed1.8, perf)
Attachments
(2 files, 1 obsolete file)
17.01 KB,
text/html
|
Details | |
3.75 KB,
patch
|
aaronlev
:
review+
neil
:
superreview+
asa
:
approval1.8b5+
|
Details | Diff | Splinter Review |
Each time I press tab, all lines of text on the screen are repainted. This is one of the core causes of bug 307545.
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.8b5?
Updated•18 years ago
|
Attachment #196611 -
Attachment is patch: false
Attachment #196611 -
Attachment mime type: text/plain → text/html
Comment 2•18 years ago
|
||
I guess this happens because of the fix for bug 151375. Since that bug got fixed, the appearance of a focus outline cause an incremental reflow.
Reporter | ||
Comment 3•18 years ago
|
||
Shouldn't we be able to do an incremental reflow and not repaint items that haven't changed?
Updated•18 years ago
|
Flags: blocking1.8b5? → blocking1.8b5+
Comment 4•18 years ago
|
||
testcase wfm Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050923 Firefox/1.4 ID:2005092307
Reporter | ||
Comment 5•18 years ago
|
||
(In reply to comment #4) > testcase wfm > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050923 > Firefox/1.4 ID:2005092307 What did you test? You need to put in debugging statements to see how many lines are repainted with each focus move. It's not a readily apparent bug otherwise, unless you're running a screen reader or possibly on a lower-end machine.
Reporter | ||
Comment 6•18 years ago
|
||
Attachment #196611 -
Attachment is obsolete: true
Assignee | ||
Comment 7•18 years ago
|
||
Try this. It seems to help a lot for me. On every focus change the ESM tells docshell the canvas no longer has focus. The docshell then invalidates the entire window. Instead we should only invalidate the window if the canvas previously had focus.
Comment 8•18 years ago
|
||
Re Comment 5 Apologies, I was looking for flickering whilst tabbing through the links on the testcase.
Reporter | ||
Comment 9•18 years ago
|
||
Comment on attachment 197507 [details] [diff] [review] fix This fixes most of the problem, which is good enough for Firefox 1.5. It's a simple fix. The only time it doesn't fix the problem is when tab is moving to or from the canvas frame, but that can get fixed in Firefox 2.0 with the ExtTextOut work.
Attachment #197507 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #197507 -
Flags: review+
Updated•18 years ago
|
Attachment #197507 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Reporter | ||
Updated•18 years ago
|
Attachment #197507 -
Flags: approval1.8b5?
Reporter | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 10•18 years ago
|
||
Aaron, is there any way for our QA to easily verify this?
Reporter | ||
Comment 11•18 years ago
|
||
(In reply to comment #10) > Aaron, is there any way for our QA to easily verify this? Not an easy way without downloading a screen reader. I already verified it. Just have QA make sure it didn't break anything on trunk. However, I think we'll see that nothing has regressed in the next day or two.
Reporter | ||
Comment 12•18 years ago
|
||
The bug this really fixed is bug 307545. Although I have already verified that this fixes that, I can have IBM QA double verify this bug via bug 307545, since they already have Window-Eyes installed and are accustomed to screen reader testing.
Updated•18 years ago
|
Attachment #197507 -
Flags: approval1.8b5? → approval1.8b5+
Comment 13•18 years ago
|
||
Did this cause 311152?
You need to log in
before you can comment on or make changes to this bug.
Description
•