620906 - Scrolling using the Scrollbar on Ckeditor is broken

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Nazar]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

I am using Ckeditor.
In old FireFox (3) and Opera all is ok.

Reproducible: Always

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Is that Issue reproducible on http://ckeditor.com/demo too?
What are the exact Steps?
What exact Version of Firefox 3 did this work with?

Comment 2

[Nazar]

Yes, that Issue is reproducible on http://ckeditor.com/demo too.
Steps? I just trying to move the vertical slider.
FireFox 3.6.13 works with CKEditor correctly.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

This regressed within Beta 1 <-> 2.

Comment 4

[aravindm]

Build worked : 
Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre
http://hg.mozilla.org/mozilla-central/rev/1a107c990c89

Build broken: 
Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre
http://hg.mozilla.org/mozilla-central/rev/5355f245b916

Pushlog : 
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a107c990c89
&tochange=5355f245b916

Comment 5

[Boris Zbarsky [:bzbarsky]]

That's http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a107c990c89&tochange=5355f245b916

There are some editor changes in there.

Comment 6

[Alice0775 White]

This problem happens on Linux too.Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20101223 Firefox/4.0b9pre ID:20101223030401


Regression window(cached hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/7ea77e6340c4
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre ID:20100713164148
Fails
http://hg.mozilla.org/mozilla-central/rev/12ea384540e3
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100713 Minefield/4.0b2pre ID:20100713193307
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7ea77e6340c4&tochange=12ea384540e3

In local build,
Build from 2a99ed409a38 : fails
Build from dbcb7142daa1 : fails
Build from 9a1de8516b43 : fails
Build from f2890f8a7220 : works
Build from 14d43898f62a : works

Candidate: 9a1de8516b43	Ehsan Akhgari — Bug 289384 - Midas Editor: Shortcut command + left/right should go to beginning/end of line; r=masayuki,bzbarsky

Comment 7

[(no longer active)]

Here is what's happening here.  CKEditor has a click handler which sets designMode to "on" and "off", respectively.  We flush when setting designMode="on", which causes the scrollbar anonymous content to be removed from the document:

#0  nsXULElement::UnbindFromTree (this=0x12529ce90, aDeep=1, aNullParent=1) at /Users/ehsanakhgari/moz/mozilla-central/content/xul/content/src/nsXULElement.cpp:921
#1  0x00000001141e66ce in nsXBLBinding::InstallAnonymousContent (this=0x121f25830, aAnonParent=0x1252bd950, aElement=0x12527a670) at /Users/ehsanakhgari/moz/mozilla-central/content/xbl/src/nsXBLBinding.cpp:360
#2  0x00000001141e9b55 in nsXBLBinding::GenerateAnonymousContent (this=0x121f25830) at /Users/ehsanakhgari/moz/mozilla-central/content/xbl/src/nsXBLBinding.cpp:691
#3  0x0000000114207ee4 in nsXBLService::LoadBindings (this=0x120701be0, aContent=0x12527a670, aURL=0x120751d70, aOriginPrincipal=0x100c61ce0, aAugmentFlag=0, aBinding=0x1252552e0, aResolveStyle=0x7fff5fbfa66c) at /Users/ehsanakhgari/moz/mozilla-central/content/xbl/src/nsXBLService.cpp:641
#4  0x0000000113ba2a06 in nsCSSFrameConstructor::AddFrameConstructionItemsInternal (this=0x11ac14e40, aState=@0x7fff5fbfa9c0, aContent=0x12527a670, aParentFrame=0x1026d5a90, aTag=0x100c50a30, aNameSpaceID=9, aSuppressWhiteSpaceOptimizations=1, aStyleContext=0x1026d5468, aFlags=3, aItems=@0x7fff5fbfa770) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5115
#5  0x0000000113ba361b in nsCSSFrameConstructor::AddFrameConstructionItems (this=0x11ac14e40, aState=@0x7fff5fbfa9c0, aContent=0x12527a670, aSuppressWhiteSpaceOptimizations=1, aParentFrame=0x1026d5a90, aItems=@0x7fff5fbfa770) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5055
#6  0x0000000113ba85ba in nsCSSFrameConstructor::ConstructFrame (this=0x11ac14e40, aState=@0x7fff5fbfa9c0, aContent=0x12527a670, aParentFrame=0x1026d5a90, aFrameItems=@0x7fff5fbfa920) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4995
#7  0x0000000113ba8bc6 in nsCSSFrameConstructor::CreateAnonymousFrames (this=0x11ac14e40, aState=@0x7fff5fbfa9c0, aParent=0x11b069b70, aParentFrame=0x1026d5a90, aPendingBinding=0x0, aChildItems=@0x7fff5fbfa920) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3911
#8  0x0000000113ba8d20 in nsCSSFrameConstructor::BeginBuildingScrollFrame (this=0x11ac14e40, aState=@0x7fff5fbfa9c0, aContent=0x11b069b70, aContentStyle=0x1026d4eb0, aParentFrame=0x1026d4a88, aScrolledPseudo=0x100c46180, aIsRoot=1, aNewFrame=@0x7fff5fbfaae0) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4249
#9  0x0000000113ba95c1 in nsCSSFrameConstructor::SetUpDocElementContainingBlock (this=0x11ac14e40, aDocElement=0x11b069b70) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:2763
#10 0x0000000113bab5d5 in nsCSSFrameConstructor::ConstructDocElementFrame (this=0x11ac14e40, aDocElement=0x11b069b70, aFrameState=0x11b08f830, aNewFrame=0x7fff5fbfafb8) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:2296
#11 0x0000000113bac672 in nsCSSFrameConstructor::ContentRangeInserted (this=0x11ac14e40, aContainer=0x0, aStartChild=0x11b069b70, aEndChild=0x0, aFrameState=0x11b08f830, aAllowLazyConstruction=0) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6920
#12 0x0000000113bad94b in nsCSSFrameConstructor::ContentInserted (this=0x11ac14e40, aContainer=0x0, aChild=0x11b069b70, aFrameState=0x11b08f830, aAllowLazyConstruction=0) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6807
#13 0x0000000113baea1a in nsCSSFrameConstructor::RecreateFramesForContent (this=0x11ac14e40, aContent=0x11b069b70, aAsyncInsert=0) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9156
#14 0x0000000113baf49a in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x11ac14e40, aChangeList=@0x7fff5fbfb220) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:8018
#15 0x0000000113bafc5e in nsCSSFrameConstructor::RestyleElement (this=0x11ac14e40, aElement=0x11b069b70, aPrimaryFrame=0x1026dbc20, aMinHint=0, aRestyleTracker=@0x11ac14ed8, aRestyleDescendants=1) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:8104
#16 0x0000000113b962f8 in mozilla::css::RestyleTracker::ProcessOneRestyle (this=0x11ac14ed8, aElement=0x11b069b70, aRestyleHint=eRestyle_Subtree, aChangeHint=0) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/RestyleTracker.cpp:156
#17 0x0000000113b94dfb in mozilla::css::RestyleTracker::ProcessRestyles (this=0x11ac14ed8) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/RestyleTracker.cpp:240
#18 0x0000000113baf9f0 in nsCSSFrameConstructor::ProcessPendingRestyles (this=0x11ac14e40) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:11653
#19 0x0000000113c3783f in PresShell::FlushPendingNotifications (this=0x11ac14200, aType=Flush_Style) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp:4856
#20 0x0000000113f0dcfe in nsDocument::FlushPendingNotifications (this=0x12267be00, aType=Flush_Style) at /Users/ehsanakhgari/moz/mozilla-central/content/base/src/nsDocument.cpp:6438
#21 0x0000000114142986 in nsHTMLDocument::EditingStateChanged (this=0x12267be00) at /Users/ehsanakhgari/moz/mozilla-central/content/html/document/src/nsHTMLDocument.cpp:3410
#22 0x0000000114143024 in nsHTMLDocument::SetDesignMode (this=0x12267be00, aDesignMode=@0x7fff5fbfc610) at /Users/ehsanakhgari/moz/mozilla-central/content/html/document/src/nsHTMLDocument.cpp:3480
#23 0x0000000114889507 in nsIDOMNSHTMLDocument_SetDesignMode (cx=0x1252c0090, obj=0x125339d68, id={asBits = 4845247296}, vp=0x7fff5fbfc930) at dom_quickstubs.cpp:20599
#24 0x000000010014ac1e in js::CallJSPropertyOpSetter (cx=0x1252c0090, op=0x1148893e2 <nsIDOMNSHTMLDocument_SetDesignMode(JSContext*, JSObject*, jsid, jsval_layout*)>, obj=0x125339d68, id={asBits = 4845247296}, vp=0x7fff5fbfc930) at jscntxtinlines.h:739
#25 0x00000001001f19bf in js::Shape::set (this=0x1017f3e20, cx=0x1252c0090, obj=0x125339d68, vp=0x7fff5fbfc930) at jsscopeinlines.h:275
#26 0x00000001001e518a in js_SetPropertyHelper (cx=0x1252c0090, obj=0x125339d68, id={asBits = 4845247296}, defineHow=1, vp=0x7fff5fbfc930, strict=0) at /Users/ehsanakhgari/moz/mozilla-central/js/src/jsobj.cpp:5540
#27 0x0000000100332b77 in js::mjit::stubs::SetName<0> (f=@0x7fff5fbfca50, origAtom=0x120cc9b40) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/StubCalls.cpp:260
#28 0x000000010037e9fc in DisabledSetPropIC<0> (f=@0x7fff5fbfca50, pic=0x11e7db898) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/PolyIC.cpp:1752
#29 0x0000000100382503 in js::mjit::ic::SetProp (f=@0x7fff5fbfca50, pic=0x11e7db898) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/PolyIC.cpp:1792
#30 0x0000000101e752b6 in ?? ()
#31 0x000000010032bbe8 in js::mjit::EnterMethodJIT (cx=0x1252c0090, fp=0x117b4b050, code=0x119d173a0, stackLimit=0x117bf4f68) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/MethodJIT.cpp:745
#32 0x000000010032bcdf in CheckStackAndEnterMethodJIT (cx=0x1252c0090, fp=0x117b4b050, code=0x119d173a0) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/MethodJIT.cpp:770
#33 0x000000010032bdf3 in js::mjit::JaegerShot (cx=0x1252c0090) at /Users/ehsanakhgari/moz/mozilla-central/js/src/methodjit/MethodJIT.cpp:787
#34 0x00000001001c5d18 in js::RunScript (cx=0x1252c0090, script=0x124ab3120, fp=0x117b4b050) at jsinterp.cpp:654
#35 0x00000001001c69fa in js::Invoke (cx=0x1252c0090, argsRef=@0x7fff5fbfcd60, flags=0) at jsinterp.cpp:737
#36 0x00000001001c7239 in js::ExternalInvoke (cx=0x1252c0090, thisv=@0x7fff5fbfcdf0, fval=@0x7fff5fbfce28, argc=1, argv=0x7fff5fbfd4a8, rval=0x7fff5fbfd0a0) at jsinterp.cpp:858
#37 0x00000001000f5848 in js::ExternalInvoke (cx=0x1252c0090, obj=0x125359688, fval=@0x7fff5fbfce28, argc=1, argv=0x7fff5fbfd4a8, rval=0x7fff5fbfd0a0) at jsinterp.h:961
#38 0x00000001000f5983 in JS_CallFunctionValue (cx=0x1252c0090, obj=0x125359688, fval={asBits = 18445477441233590160, debugView = {payload47 = 4919236496, tag = JSVAL_TAG_OBJECT}, s = {payload = {i32 = 624269200, u32 = 624269200, why = 624269200, word = 18445477441233590160}}, asDouble = -nan(0xb800125359790), asPtr = 0xfffb800125359790}, argc=1, argv=0x7fff5fbfd4a8, rval=0x7fff5fbfd0a0) at /Users/ehsanakhgari/moz/mozilla-central/js/src/jsapi.cpp:5077
#39 0x00000001147ff751 in nsXPCWrappedJSClass::CallMethod (this=0x120763970, wrapper=0x123d8de30, methodIndex=3, info=0x10113e718, nativeParams=0x7fff5fbfd600) at /Users/ehsanakhgari/moz/mozilla-central/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
#40 0x00000001147f6760 in nsXPCWrappedJS::CallMethod (this=0x123d8de30, methodIndex=3, info=0x10113e718, params=0x7fff5fbfd600) at /Users/ehsanakhgari/moz/mozilla-central/js/src/xpconnect/src/xpcwrappedjs.cpp:588
#41 0x00000001008fae0e in PrepareAndDispatch (self=0x123d2fa10, methodIndex=3, args=0x7fff5fbfd780, gpregs=0x7fff5fbfd700, fpregs=0x7fff5fbfd730) at /Users/ehsanakhgari/moz/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
#42 0x00000001008f9883 in SharedStub () at xpt_struct.h:332
#43 0x0000000114033b06 in nsEventListenerManager::HandleEventSubType (this=0x123d8deb0, aListenerStruct=0x123d8def8, aListener=0x123d2fa10, aDOMEvent=0x12529cc30, aCurrentTarget=0x11b069b70, aPhaseFlags=2, aPusher=0x7fff5fbfdd00) at /Users/ehsanakhgari/moz/mozilla-central/content/events/src/nsEventListenerManager.cpp:1114
#44 0x0000000114033f81 in nsEventListenerManager::HandleEventInternal (this=0x123d8deb0, aPresContext=0x11ac12d40, aEvent=0x7fff5fbfe500, aDOMEvent=0x7fff5fbfdce0, aCurrentTarget=0x11b069b70, aFlags=2, aEventStatus=0x7fff5fbfdce8, aPusher=0x7fff5fbfdd00) at /Users/ehsanakhgari/moz/mozilla-central/content/events/src/nsEventListenerManager.cpp:1209
#45 0x00000001140641d7 in nsEventListenerManager::HandleEvent (this=0x123d8deb0, aPresContext=0x11ac12d40, aEvent=0x7fff5fbfe500, aDOMEvent=0x7fff5fbfdce0, aCurrentTarget=0x11b069b70, aFlags=2, aEventStatus=0x7fff5fbfdce8, aPusher=0x7fff5fbfdd00) at nsEventListenerManager.h:146
#46 0x0000000114064382 in nsEventTargetChainItem::HandleEvent (this=0x101346830, aVisitor=@0x7fff5fbfdcd0, aFlags=2, aMayHaveNewListenerManagers=0, aPusher=0x7fff5fbfdd00) at /Users/ehsanakhgari/moz/mozilla-central/content/events/src/nsEventDispatcher.cpp:212
#47 0x0000000114062890 in nsEventTargetChainItem::HandleEventTargetChain (this=0x1013467c0, aVisitor=@0x7fff5fbfdcd0, aFlags=6, aCallback=0x7fff5fbfde10, aMayHaveNewListenerManagers=0, aPusher=0x7fff5fbfdd00) at /Users/ehsanakhgari/moz/mozilla-central/content/events/src/nsEventDispatcher.cpp:364
#48 0x000000011406342a in nsEventDispatcher::Dispatch (aTarget=0x11b08e370, aPresContext=0x11ac12d40, aEvent=0x7fff5fbfe500, aDOMEvent=0x0, aEventStatus=0x7fff5fbfe15c, aCallback=0x7fff5fbfde10, aTargets=0x0) at /Users/ehsanakhgari/moz/mozilla-central/content/events/src/nsEventDispatcher.cpp:628
#49 0x0000000113c265a7 in PresShell::HandleEventInternal (this=0x11ac14200, aEvent=0x7fff5fbfe500, aView=0x11ac13dd0, aStatus=0x7fff5fbfe15c) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp:6951
#50 0x0000000113c273ad in PresShell::HandlePositionedEvent (this=0x11ac14200, aView=0x11ac13dd0, aTargetFrame=0x1026d8760, aEvent=0x7fff5fbfe500, aEventStatus=0x7fff5fbfe15c) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp:6785
#51 0x0000000113c36147 in PresShell::HandleEvent (this=0x120767d20, aView=0x1207660d0, aEvent=0x7fff5fbfe500, aDontRetargetEvents=0, aEventStatus=0x7fff5fbfe15c) at /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp:6635
#52 0x000000011423f41d in nsViewManager::HandleEvent (this=0x120766060, aView=0x1207660d0, aEvent=0x7fff5fbfe500) at /Users/ehsanakhgari/moz/mozilla-central/view/src/nsViewManager.cpp:1092
#53 0x0000000114243415 in nsViewManager::DispatchEvent (this=0x120766060, aEvent=0x7fff5fbfe500, aView=0x1207660d0, aStatus=0x7fff5fbfe36c) at /Users/ehsanakhgari/moz/mozilla-central/view/src/nsViewManager.cpp:1070
#54 0x000000011423cab4 in HandleEvent (aEvent=0x7fff5fbfe500) at /Users/ehsanakhgari/moz/mozilla-central/view/src/nsView.cpp:161
#55 0x0000000113936dfd in nsChildView::DispatchEvent (this=0x120766150, event=0x7fff5fbfe500, aStatus=@0x7fff5fbfe48c) at /Users/ehsanakhgari/moz/mozilla-central/widget/src/cocoa/nsChildView.mm:1786
#56 0x0000000113932d94 in nsChildView::DispatchWindowEvent (this=0x120766150, event=@0x7fff5fbfe500) at /Users/ehsanakhgari/moz/mozilla-central/widget/src/cocoa/nsChildView.mm:1796
#57 0x000000011394131b in -[ChildView mouseDown:] (self=0x120767080, _cmd=0x7fff88ecbcb0, theEvent=0x125259220) at /Users/ehsanakhgari/moz/mozilla-central/widget/src/cocoa/nsChildView.mm:3244

Later on, when we attempt to handle the event on the XUL content, it is no longer bound to the document, and we'll assert like this:

###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp, line 6512
###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file /Users/ehsanakhgari/moz/mozilla-central/layout/base/nsPresShell.cpp, line 6570
###!!! ASSERTION: must have binding parent when in native anonymous subtree with a parent node: '!IsInNativeAnonymousSubtree() || GetBindingParent() || !GetParent()', file ../../../dist/include/nsIContent.h, line 263

And fail to scroll.

I've added a minimized test case to the URL field.  CCing some folks who might have an idea about what the best way to solve this would be...

Comment 8

[(no longer active)]

In particular, I think we would want to maintain the capturing content across scrollbar anonymous content reconstruction, but looking at the code, this should be very hard to do...

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Trying to recover anonymous content across binding instantiations sounds very scary and not something we can do for FF4 I'd say.

What made this work in previous releases?

Could we change some action here to be asynchronous so that we never end up rebuilding the scrollbar content since we see that we're still in the same mode as before?

Comment 10

[Timothy Nikkel (:tnikkel)]

(In reply to comment #9)
> What made this work in previous releases?

Oh, because we added that flush in bug 289384.

Comment 11

[(no longer active)]

(In reply to comment #9)
> Trying to recover anonymous content across binding instantiations sounds very
> scary and not something we can do for FF4 I'd say.
> 
> What made this work in previous releases?

Timothy is right in comment 10.

> Could we change some action here to be asynchronous so that we never end up
> rebuilding the scrollbar content since we see that we're still in the same mode
> as before?

Would it work though?  The user, when moving the thumb, would hold the mouse down long enough for anything we do async to finish...

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The testcase in the url sets displaymode immediately back to what it was, so no asynchronous events can fire in between. Maybe that isn't what the website is doing though?

Comment 13

[(no longer active)]

Actually the flush pending notification there is not the cause of the issue.  This can also be triggered by any other flush (such as the one before painting).  The issue is that adding and removing the editor stylesheets will apply bindings to the document, which causes all of the anonymous content associated with the document to be reconstructed...

Comment 14

[Timothy Nikkel (:tnikkel)]

So then this problem was happening before?

Comment 15

[(no longer active)]

(In reply to comment #14)
> So then this problem was happening before?

No, because the code to attach the binding to :root was added at the same time as the added flush call.  The real culprit is the -moz-binding rule in designmode.css.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This would be a pretty scary change this late in the game, but *maybe* we could be smart enough to not regenerate frames when a binding is added if the binding doesn't contain a <content>.

Comment 17

[(no longer active)]

I tried a bunch of things here, and even though it saddens me, I think the best way to address this issue at this point with the least possibility of regressions is to back bug 289384 out.  :(

Comment 18

[Boris Zbarsky [:bzbarsky]]

> if the binding doesn't contain a <content>

Or an xbl:inherits="prefix:localName".  Or inherit from a binding that has one of those.  I _think_ that might be everything, but I'd need to double-check.

Oh, and we'd need to write new codepaths for actually _applying_ the binding.  Right now that happens at frame construction time...

It sort of saddens me that we have to overload XBL for attaching keybindings.  :(

Comment 19

[(no longer active)]

(In reply to comment #18)
> > if the binding doesn't contain a <content>
> 
> Or an xbl:inherits="prefix:localName".  Or inherit from a binding that has one
> of those.  I _think_ that might be everything, but I'd need to double-check.
> 
> Oh, and we'd need to write new codepaths for actually _applying_ the binding. 
> Right now that happens at frame construction time...
> 
> It sort of saddens me that we have to overload XBL for attaching keybindings. 
> :(

Yeah, we need to move away from that.  I'm thinking of fixing bug 289384 in another way post 2.0, because I don't feel comfortable with the amount of risk in the suggested fix in comment 16 and 18.

Comment 20

[(no longer active)]

Attachment: Patch (v1)

Comment 21

[(no longer active)]

Attachment: Part 2: fix the a11y test

This part fixes the accessibility tests failures caused by the changes made in bug 616082.  The test changes in that bug were merely relying of implicit side-effects of the -moz-binding style being applied to the document's root, and this assumption is not going to be valid any more with this bug's patch.

Comment 22

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 502896 [details] [diff] [review]
Part 2: fix the a11y test

r=me since I can't think of a reason we need to rely on the REORDER happening right after a designmode on/off. I'm basing this r+ on my understanding that you are no longer flushing layout right away. I would normally ask for Alex's review here but I understand this is for a hard blocker and don't want to slow you down. Pinging Alex and Marco for feedback anyways in case we want to do follow up.

Comment 23

[Marco Zehe (:MarcoZ)]

Comment on attachment 502896 [details] [diff] [review]
Part 2: fix the a11y test

I believe to land this patch, it is a safe bet to revert these tests for now.
If we need any events tested after all, we can either reopen bug 616082, or file a followup bug for the tests.

Comment 24

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/985c54525bc0
http://hg.mozilla.org/mozilla-central/rev/556f7620b78f

Comment 25

[alexander :surkov (:asurkov)]

Comment on attachment 502896 [details] [diff] [review]
Part 2: fix the a11y test

f+ per comment #21 (mochitests after the bug 498015 are passed what was a reason of those mochitests changes).