Closed
Bug 633271
Opened 14 years ago
Closed 14 years ago
Simplify nsEventStateManager::SetContentState
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla5
People
(Reporter: bzbarsky, Assigned: bzbarsky)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
7.54 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
16.29 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
It's far more complicated than it needs to be.
![]() |
Assignee | |
Comment 1•14 years ago
|
||
Attachment #511452 -
Flags: review?(enndeakin)
![]() |
Assignee | |
Comment 2•14 years ago
|
||
Attachment #511453 -
Flags: review?(dbaron)
![]() |
Assignee | |
Updated•14 years ago
|
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [need review]
![]() |
Assignee | |
Comment 3•14 years ago
|
||
Attachment #511644 -
Flags: review?(dbaron)
![]() |
Assignee | |
Updated•14 years ago
|
Attachment #511453 -
Attachment is obsolete: true
Attachment #511453 -
Flags: review?(dbaron)
Updated•14 years ago
|
Attachment #511452 -
Flags: review?(enndeakin) → review+
Depends on: 313351
Comment on attachment 511644 [details] [diff] [review]
part 2. Simplify nsEventStateManager::SetContentState.
Making notifyContent1, notifyContent2, and commonAncestor into weak pointers scares me a little -- maybe they should be nsCOMPtrs?
r=dbaron
Attachment #511644 -
Flags: review?(dbaron) → review+
![]() |
Assignee | |
Comment 5•14 years ago
|
||
> maybe they should be nsCOMPtrs?
Yeah, I suppose that would be safer. In theory ContentStatesChanged observers should't do anything evil and I think we have code that depends on that, but for now this is the safe thing to do. Made that change.
![]() |
Assignee | |
Updated•14 years ago
|
Whiteboard: [need review] → [need landing]
![]() |
Assignee | |
Comment 6•14 years ago
|
||
Pushed:
http://hg.mozilla.org/projects/cedar/rev/728077e8679d
http://hg.mozilla.org/projects/cedar/rev/c8c2edd1f1ee
Flags: in-testsuite-
Whiteboard: [need landing] → fixed-in-cedar
Target Milestone: --- → mozilla2.2
Comment 7•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/728077e8679d
http://hg.mozilla.org/mozilla-central/rev/c8c2edd1f1ee
Whiteboard: fixed-in-cedar
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 8•13 years ago
|
||
This broke DOM Inspector which expects to be able to set the focus state. (I won't file a bug because I don't know which way around to file it.)
![]() |
Assignee | |
Comment 9•13 years ago
|
||
How could setting the focus state have possibly worked before this patch? The GetContentState() call would not set the focus flag, since the focus manager would not know anything about the SetContentState call that DOM Inspector made.
So I can believe that setting focus state in DOMI is broken, but I really doubt that it was this change (as opposed to the change that added the focus manager) broke it.
Comment 10•13 years ago
|
||
(In reply to Boris Zbarsky from comment #9)
> How could setting the focus state have possibly worked before this patch?
You're right, it didn't, but you added an assertion that I didn't get before, and I hadn't realised that this was because getting the state already failed.
![]() |
Assignee | |
Comment 11•13 years ago
|
||
Ah, I added the assertion to catch any callers who might think their code is doing something when it actually didn't.... ;) Sounds like it worked.
Do we need an API for inpsector to set focus state? It should be pretty doable.
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•