Closed
Bug 707039
Opened 13 years ago
Closed 6 years ago
[SeaMonkey] mochitest-chrome: "TEST-UNEXPECTED-FAIL ... textLTR.openPopup is not a function at ... test_bug649840.xul:39"
Categories
(SeaMonkey :: Autocomplete, defect, P2)
SeaMonkey
Autocomplete
Tracking
(seamonkey2.6 wontfix, seamonkey2.7 wontfix, seamonkey2.8 wontfix, seamonkey2.9 verified)
RESOLVED
FIXED
seamonkey2.9
People
(Reporter: sgautherie, Assigned: sgautherie)
References
(Blocks 1 open bug, )
Details
(Keywords: rtl, Whiteboard: [perma-orange])
Attachments
(4 files, 7 obsolete files)
8.31 KB,
patch
|
neil
:
review+
Callek
:
approval-comm-aurora-
Callek
:
approval-comm-beta-
|
Details | Diff | Splinter Review |
11.13 KB,
patch
|
neil
:
review+
Callek
:
approval-comm-aurora-
Callek
:
approval-comm-beta-
|
Details | Diff | Splinter Review |
1.15 KB,
patch
|
neil
:
review+
Callek
:
approval-comm-aurora-
Callek
:
approval-comm-beta-
|
Details | Diff | Splinter Review |
2.51 KB,
patch
|
neil
:
review+
Callek
:
approval-comm-aurora+
|
Details | Diff | Splinter Review |
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1322765602.1322769171.17358.gz&fulltext=1 OS X 10.6 comm-central-trunk debug test mochitest-other on 2011/12/01 10:53:22 { ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_bug649840.xul | [SimpleTest/SimpleTest.js, window.onerror] - An error occurred: textLTR.openPopup is not a function at chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_bug649840.xul:39 } http://hg.mozilla.org/mozilla-central/rev/c17c9e2c8845 *Should the autocomplete.xml part be ported to SeaMonkey? *Is "textLTR.openPopup()" Firefox specific?
Comment 1•13 years ago
|
||
(In reply to Serge Gautherie from comment #0) > *Should the autocomplete.xml part be ported to SeaMonkey? Probably. > *Is "textLTR.openPopup()" Firefox specific? XPFE autocomplete uses separate popups for results and history, therefore calling them the resultsPopup and the historyPopup. (For some strange reason it uses openResultPopup and closeResultPopup). I suppose we could rename them, or maybe just forward the Toolkit names to the XPFE code.
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 2•13 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #1) > XPFE autocomplete uses separate popups for results and history, therefore > calling them the resultsPopup and the historyPopup. (For some strange reason > it uses openResultPopup and closeResultPopup). I suppose we could rename > them, or maybe just forward the Toolkit names to the XPFE code. Let's fix this part (first). I assume using Toolkit names (only) should be just fine. (Untested :-|)
Attachment #579206 -
Flags: review?(neil)
Comment 3•13 years ago
|
||
Comment on attachment 579206 [details] [diff] [review] (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup() [Checked in: Comment 31] r=me once this is tested.
Attachment #579206 -
Flags: review?(neil) → review+
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 4•13 years ago
|
||
Comment on attachment 579206 [details] [diff] [review] (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup() [Checked in: Comment 31] (In reply to neil@parkwaycc.co.uk from comment #3) > r=me once this is tested. [Mozilla/5.0 (Windows NT 5.0; rv:11.0a1) Gecko/20111206 Firefox/11.0a1 SeaMonkey/2.8a1] (nightly, 2011-12-06-00-30-01-comm-central-trunk) This patch seems to work :-)
Assignee | ||
Comment 5•13 years ago
|
||
With patch Av1, the next failure is: { [...] - textLTR.popup is undefined at chrome://mochitests/content/chrome/toolkit/content/tests/chrome/test_bug649840.xul:44 } 'popup' is part of 'nsIAutoCompleteInput' which XPFE autocomplete.xml doesn't implement (yet). Adding a 'popup' field with 'this.resultsPopup;' fixes that. http://mxr.mozilla.org/comm-central/search?string=resultsPopup&case=1 Could I simply/instead rename 'resultsPopup' to 'popup'? (Additionally,) Should XPFE lazily create the popup, as Toolkit does? Should XPFE implement more/all of 'nsIAutoCompleteInput'? ***** With 'popup' field, next failures are: { LTR textbox test fails - got , expected ltr RTL textbox test fails - got , expected rtl RTL-switched textbox test fails - got , expe cted rtl LTR-switched textbox test fails - got , expe cted ltr } I added |this.resultsPopup.mInputElt = this;| (fwiw) and copied bug 649840 fix, but that doesn't help, as is :-/
Attachment #579357 -
Flags: feedback?(neil)
Comment 6•13 years ago
|
||
(In reply to Serge Gautherie from comment #5) > 'popup' is part of 'nsIAutoCompleteInput' which XPFE autocomplete.xml > doesn't implement (yet). > Adding a 'popup' field with 'this.resultsPopup;' fixes that. > > http://mxr.mozilla.org/comm-central/search?string=resultsPopup&case=1 > Could I simply/instead rename 'resultsPopup' to 'popup'? Probably. (One of the urlbarBindings.xml versions is an unrelated variable, but the other would need to be renamed.) > Should XPFE lazily create the popup, as Toolkit does? Don't see the benefit of this (yet). > Should XPFE implement more/all of 'nsIAutoCompleteInput'? This is really designed so that the C++ backend can communicate with the XBL; we've already implemented all we need for form fill to work, so anything else might not be worthwhile.
Assignee | ||
Comment 7•13 years ago
|
||
Attachment #579493 -
Flags: review?(neil)
Assignee | ||
Comment 8•13 years ago
|
||
Attachment #579495 -
Flags: review?(neil)
Assignee | ||
Comment 9•13 years ago
|
||
Same test failure(s) with patches (Bv1 + Cv1-SM) + Dv1 as with patch Bv0. I tried to check the test page with DOMi: afaict, this patch makes no difference :-| Helpwanted...
Attachment #579357 -
Attachment is obsolete: true
Attachment #579357 -
Flags: feedback?(neil)
Attachment #579518 -
Flags: feedback?(neil)
Comment 10•13 years ago
|
||
The problem is that attachment 579518 [details] [diff] [review] fixes the bug for web page autocomplete but test_bug649840 only tests it for chrome autocomplete...
Updated•13 years ago
|
Attachment #579493 -
Flags: review?(neil) → review+
Updated•13 years ago
|
Attachment #579495 -
Flags: review?(neil) → review+
Comment 11•13 years ago
|
||
Comment on attachment 579518 [details] [diff] [review] (Dv1) XPFE autocomplete.xml: Adjust the direction of the autocomplete popup list based on the textbox direction >+ // Adjust the direction of the autocomplete popup list based on the textbox direction, bug 707039 So, given that, this comment isn't actually true ;-) >+ var popupDirection = aElement.ownerDocument.defaultView.getComputedStyle(aElement).direction; >+ this.style.direction = popupDirection; Hardly seems worth the trouble of a separate variable. Also the line is a little on the long side. >+ I could live without these blank lines.
Attachment #579518 -
Flags: feedback?(neil) → feedback+
Assignee | ||
Comment 12•13 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #10) > The problem is that attachment 579518 [details] [diff] [review] fixes the bug for web page autocomplete > but test_bug649840 only tests it for chrome autocomplete... Hum, I don't have enough clue to know how to fix this: helpwanted. (In reply to Ehsan Akhgari [:ehsan] from bug 649840 comment #19) > Is this possible to test for normal HTML input elements too? > This test ensures that this wouldn't break for XUL textbox'es, > but I'm more worried about <html:input> textboxes as used on the web. > But I have no idea how to do this test. Unanswered... (In reply to neil@parkwaycc.co.uk from bug 649840 comment #23) > What actually happens is that there's an form fill controller that attaches > the popup to whichever HTML input you're autocompleting, as distinct from > the regular controller in a XUL autocomplete which always attaches the popup > to the same XUL textbox. Do I need to port (the code leading to) |popup.mInput = this;| too? If yes, then I'm not sure where/how. (Ftr, it didn't seem to help the way I did it in patch Bv0.) If not, then I have no idea.
Keywords: rtl
Assignee | ||
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86_64 → All
Comment 13•13 years ago
|
||
No, you would have to tweak open[Result]Popup() (note that this is a method on the autocomplete field, so what was aElement is now this, defaultView is now window and this is now this.[result]popup).
Assignee | ||
Comment 14•13 years ago
|
||
Dv1, with comment 13 suggestion(s). In openPopup(), I assume |this.focused| should not matter. And, based on existing FF ans SM codes, I assume |this.mMenuOpen| should/can matter, though maybe it should not: please double-check. (In reply to neil@parkwaycc.co.uk from comment #11) > >+ // Adjust the direction of the autocomplete popup list based on the textbox direction, bug 707039 > So, given that, this comment isn't actually true ;-) Please, suggest better comments.
Attachment #579518 -
Attachment is obsolete: true
Attachment #579893 -
Flags: review?(neil)
Assignee | ||
Comment 15•13 years ago
|
||
Comment on attachment 579893 [details] [diff] [review] (Dv2) XPFE autocomplete.xml: Adjust the direction of the (Chrome and content) autocomplete popup list based on the textbox direction Review of attachment 579893 [details] [diff] [review]: ----------------------------------------------------------------- ::: xpfe/components/autocomplete/resources/content/autocomplete.xml @@ +1175,5 @@ > + this.popup.style.direction = window.getComputedStyle(this).direction; > + > + if (this.focused && > + (this.getResultCount() >= this.minResultsForPopup || > + this.mFailureItems)) { Ah, with a -1 space increment on these 2 lines ;->
Comment 16•13 years ago
|
||
Comment on attachment 579893 [details] [diff] [review] (Dv2) XPFE autocomplete.xml: Adjust the direction of the (Chrome and content) autocomplete popup list based on the textbox direction >+ if (this.mMenuOpen) >+ return; >+ >+ // (Chrome) Adjust the direction of the autocomplete popup list >+ // based on the textbox direction. (Bug 707039) >+ this.popup.style.direction = window.getComputedStyle(this).direction; >+ >+ if (this.focused && >+ (this.getResultCount() >= this.minResultsForPopup || >+ this.mFailureItems)) { > var w = this.boxObject.width; > if (w != this.popup.boxObject.width) > this.popup.setAttribute("width", w); As with the width adjustment, we only need to do this when we open the popup. (Compare the code for the content autocomplete.)
Assignee | ||
Comment 17•13 years ago
|
||
> (In reply to Ehsan Akhgari [:ehsan] from bug 649840 comment #19) > > Is this possible to test for normal HTML input elements too? > > Unanswered... Now answered in bug 649840 comment 40.
Product: Toolkit → SeaMonkey
QA Contact: autocomplete → autocomplete
Assignee | ||
Comment 18•13 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #16) > Comment on attachment 579893 [details] [diff] [review] [diff] [details] [review] > (Dv2) XPFE autocomplete.xml: Adjust the direction of the (Chrome and > content) autocomplete popup list based on the textbox direction > > >+ if (this.mMenuOpen) > >+ return; > >+ > >+ // (Chrome) Adjust the direction of the autocomplete popup list > >+ // based on the textbox direction. (Bug 707039) > >+ this.popup.style.direction = window.getComputedStyle(this).direction; > >+ > >+ if (this.focused && > >+ (this.getResultCount() >= this.minResultsForPopup || > >+ this.mFailureItems)) { > > var w = this.boxObject.width; > > if (w != this.popup.boxObject.width) > > this.popup.setAttribute("width", w); > As with the width adjustment, we only need to do this when we open the popup. > (Compare the code for the content autocomplete.) I assumed so, but I don't know how (else) that should translate into code :-/ Do you mean to "if (dir != dir)" first? At both places? |if (this.focused)| can't be added, as the test would fail, unless .focus() calls are added to it.
Comment 19•13 years ago
|
||
(In reply to Serge Gautherie (:sgautherie) from comment #18) > Do you mean to "if (dir != dir)" first? At both places? No, I didn't. > |if (this.focused)| can't be added, as the test would fail, unless .focus() > calls are added to it. Bah, this turned out to be harder than I imagined :-( Perhaps we would be better off writing the content test, then we could arrange for this test to be skipped on SeaMonkey.
Assignee | ||
Comment 20•12 years ago
|
||
This "workaround" is enough to update XPFE autocomplete with { if (this.mMenuOpen || !this.focused) return; } but not the other condition(s). Would that be acceptable (at least ftb)? I even wonder whether Toolkit apps should do that focus() anyway: Toolkit autocomplete code doesn't require it, but wouldn't that be more like real life behavior? (I can file a bug about adding a content test and reworking the XPFE part as need be.) Otherwise, the only solution is indeed to skip this whole test :-/
Attachment #580038 -
Flags: review?(neil)
Assignee | ||
Comment 21•12 years ago
|
||
(In reply to Serge Gautherie (:sgautherie) from comment #20) > Otherwise, the only solution is indeed to skip this whole test :-/ Or the test needs to be modified to satisfy those conditions too. (But I don't know how to do that.)
Assignee | ||
Comment 22•12 years ago
|
||
(In reply to Serge Gautherie (:sgautherie) from comment #20) > I even wonder whether Toolkit apps should do that focus() anyway: > Toolkit autocomplete code doesn't require it, but wouldn't that be more like > real life behavior? Fwiw, not directly related, but I noticed by chance bug 700199, which has parts about focus and autocomplete :-|
Assignee | ||
Comment 23•12 years ago
|
||
(In reply to Serge Gautherie (:sgautherie) from comment #22) (Just in case, should Toolkit autocomplete check for focus like XPFE autocomplete does?)
Comment 24•12 years ago
|
||
(In reply to Serge Gautherie from comment #21) > Or the test needs to be modified to satisfy those conditions too. > (But I don't know how to do that.) minresultsforpopup="0" perhaps?
Comment 25•12 years ago
|
||
Comment on attachment 579893 [details] [diff] [review] (Dv2) XPFE autocomplete.xml: Adjust the direction of the (Chrome and content) autocomplete popup list based on the textbox direction Minusing as per previous comment(s).
Attachment #579893 -
Flags: review?(neil) → review-
Comment 26•12 years ago
|
||
Comment on attachment 580038 [details] [diff] [review] (Ev1) (Toolkit, Chrome) test_bug649840.xul: Add focus() calls when run with SeaMonkey I don't see why you need to special-case the focusing code.
Attachment #580038 -
Flags: review?(neil) → review-
Assignee | ||
Comment 27•12 years ago
|
||
Dv2, with comment 16 suggestion(s).
Attachment #579893 -
Attachment is obsolete: true
Attachment #580311 -
Flags: review?(neil)
Assignee | ||
Comment 28•12 years ago
|
||
Ev1, with comment 24 suggestion(s). (In reply to neil@parkwaycc.co.uk from comment #26) > I don't see why you need to special-case the focusing code. That was just to prevent possible complains (of uselessness) from a "Firefox" point of view.
Attachment #580038 -
Attachment is obsolete: true
Attachment #580312 -
Flags: review?(neil)
Assignee | ||
Comment 29•12 years ago
|
||
Neil, ping for review. (In reply to Serge Gautherie (:sgautherie) from comment #14) > (In reply to neil@parkwaycc.co.uk from comment #11) > > >+ // Adjust the direction of the autocomplete popup list based on the textbox direction, bug 707039 > > So, given that, this comment isn't actually true ;-) > > Please, suggest better comments.
Assignee | ||
Comment 30•12 years ago
|
||
Neil, ping for review. (see comment 29)
Assignee | ||
Updated•12 years ago
|
Attachment #579206 -
Flags: approval-comm-beta?
Attachment #579206 -
Flags: approval-comm-aurora?
Assignee | ||
Updated•12 years ago
|
Attachment #579493 -
Flags: approval-comm-beta?
Attachment #579493 -
Flags: approval-comm-aurora?
Assignee | ||
Updated•12 years ago
|
Attachment #579495 -
Flags: approval-comm-beta?
Attachment #579495 -
Flags: approval-comm-aurora?
Assignee | ||
Updated•12 years ago
|
Attachment #580311 -
Flags: approval-comm-beta?
Attachment #580311 -
Flags: approval-comm-aurora?
Assignee | ||
Comment 31•12 years ago
|
||
Comment on attachment 579206 [details] [diff] [review] (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup() [Checked in: Comment 31] https://hg.mozilla.org/mozilla-central/rev/5af79a8f877e
Attachment #579206 -
Attachment description: (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup() → (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup()
[Checked in: Comment 31]
Assignee | ||
Comment 32•12 years ago
|
||
Comment on attachment 579493 [details] [diff] [review] (Bv1) XPFE autocomplete.xml: Rename resultsPopup to popup [Checked in: Comment 32] https://hg.mozilla.org/mozilla-central/rev/34cbeb81ea8e
Attachment #579493 -
Attachment description: (Bv1) XPFE autocomplete.xml: Rename resultsPopup to popup → (Bv1) XPFE autocomplete.xml: Rename resultsPopup to popup
[Checked in: Comment 32]
Assignee | ||
Comment 33•12 years ago
|
||
Comment on attachment 579495 [details] [diff] [review] (Cv1-SM) XPFE autocomplete.xml: Rename resultsPopup to popup [Checked in: Comment 33] http://hg.mozilla.org/comm-central/rev/39923c3c85c3
Attachment #579495 -
Attachment description: (Cv1-SM) XPFE autocomplete.xml: Rename resultsPopup to popup → (Cv1-SM) XPFE autocomplete.xml: Rename resultsPopup to popup
[Checked in: Comment 33]
Assignee | ||
Updated•12 years ago
|
status-seamonkey2.7:
--- → affected
status-seamonkey2.8:
--- → affected
Target Milestone: --- → seamonkey2.9
Comment 34•12 years ago
|
||
Besides tests, what is the benefit for these patches landing on branch?
Assignee | ||
Comment 35•12 years ago
|
||
"approval-comm-*=?": (In reply to Justin Wood (:Callek) from comment #34) > Besides tests, what is the benefit for these patches landing on branch? Patches A and B+C might help with extension compatibility (or not). Rtl fix will be patch D. I could trivially make a branch version of it that does not depend on patch B(+C). Test fix (for SM case) will be patch E. I would request "approval-mozilla-*=?" to go along previous real SM code fix(es). Hence, we should at lest land (a tweaked) patch D on branches. If you don't approve even that, I won't insist as this bug is not a regression.
Assignee | ||
Comment 36•12 years ago
|
||
Neil, ping for review. (see comment 29)
Assignee | ||
Updated•12 years ago
|
Priority: -- → P2
Comment 37•12 years ago
|
||
I've just thought of a sneaky way to make the chrome test pass on SeaMonkey. Instead of testing the style property, test the computed style of the element! This will trivially always be the same on SeaMonkey because of CSS inheritance.
Comment 38•12 years ago
|
||
Comment on attachment 579206 [details] [diff] [review] (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup() [Checked in: Comment 31] Not worth the branch landings
Attachment #579206 -
Flags: approval-comm-beta?
Attachment #579206 -
Flags: approval-comm-beta-
Attachment #579206 -
Flags: approval-comm-aurora?
Attachment #579206 -
Flags: approval-comm-aurora-
Updated•12 years ago
|
Attachment #579493 -
Flags: approval-comm-beta?
Attachment #579493 -
Flags: approval-comm-beta-
Attachment #579493 -
Flags: approval-comm-aurora?
Attachment #579493 -
Flags: approval-comm-aurora-
Updated•12 years ago
|
Attachment #579495 -
Flags: approval-comm-beta?
Attachment #579495 -
Flags: approval-comm-beta-
Attachment #579495 -
Flags: approval-comm-aurora?
Attachment #579495 -
Flags: approval-comm-aurora-
Updated•12 years ago
|
Attachment #580311 -
Flags: approval-comm-beta?
Attachment #580311 -
Flags: approval-comm-beta-
Attachment #580311 -
Flags: approval-comm-aurora?
Attachment #580311 -
Flags: approval-comm-aurora-
Comment 39•12 years ago
|
||
If the un-checked-in parts get review after the uplift, request approval though, I might be convinced to get these remaining two patches on the same branch as the first 3 patches.
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Comment 40•12 years ago
|
||
Ev2, with comment 37 suggestion(s). (In reply to neil@parkwaycc.co.uk from comment #37) > I've just thought of a sneaky way to make the chrome test pass on SeaMonkey. > Instead of testing the style property, test the computed style of the > element! > This will trivially always be the same on SeaMonkey because of CSS > inheritance. Like this? This actually always succeeds, even without patch Dv3 fix: either this is not the right way to test this bug, or at least the chrome part of the fix would be unneeded...
Attachment #591428 -
Flags: review?(neil)
Comment 41•12 years ago
|
||
(In reply to Serge Gautherie from comment #40) > This actually always succeeds, even without patch Dv3 fix: > either this is not the right way to test this bug, or at least the chrome > part of the fix would be unneeded... Indeed, the chrome part of the fix isn't needed on SeaMonkey, because our popup automatically inherits the direction from our autocomplete widget.
Comment 42•12 years ago
|
||
Comment on attachment 591428 [details] [diff] [review] (Ev3) (Toolkit, Chrome) test_bug649840.xul: Use window.getComputedStyle() to succeed on XPFE autocomplete too [Test removed in bug 649840] (I wasn't sure whether it was worth changing both halves of the is() to match.)
Attachment #591428 -
Flags: review?(neil) → review+
Assignee | ||
Comment 43•12 years ago
|
||
(In reply to Serge Gautherie (:sgautherie) from comment #40) > This actually always succeeds, even without patch Dv3 fix: Same results for patch Ev3 with FF 12a1: *getComputedStyle() always succeeds, even after removing fix from bug 649840. *.style fails without that fix. > either this is not the right way to test this bug, or at least the chrome > part of the fix would be unneeded... Then I still wonder: are both syntax actually checking the "same" thing? isn't checking .style (patch Ev2) needed to actually test FF (and SM) fix? (as in getComputedStyle() seems to make this test useless, at least wrt bug 649840 fix.) (In reply to neil@parkwaycc.co.uk from comment #41) > Indeed, the chrome part of the fix isn't needed on SeaMonkey, because our > popup automatically inherits the direction from our autocomplete widget. I am not sure what to think: see Firefox (bug and) results... (In reply to neil@parkwaycc.co.uk from comment #42) > (I wasn't sure whether it was worth changing both halves of the is() to > match.) I did ask myself too: I think we want to compare to exactly what was set, as it is currently done.
Assignee | ||
Comment 44•12 years ago
|
||
Dv3, with comment 41 suggestion(s).
Attachment #580311 -
Attachment is obsolete: true
Attachment #580311 -
Flags: review?(neil)
Attachment #594474 -
Flags: review?(neil)
Assignee | ||
Updated•12 years ago
|
Attachment #580311 -
Flags: approval-comm-beta-
Attachment #580311 -
Flags: approval-comm-aurora-
Assignee | ||
Updated•12 years ago
|
Attachment #580312 -
Attachment description: (Ev2) (Toolkit, Chrome) test_bug649840.xul: Add minresultsforpopup="0" and .focus() to succeed on XPFE autocomplete too → (Ev2) (Toolkit, Chrome) test_bug649840.xul: Add minresultsforpopup="0" and .focus() to succeed on XPFE autocomplete too
[Test removed in bug 649840]
Attachment #580312 -
Attachment is obsolete: true
Attachment #580312 -
Flags: review?(neil)
Assignee | ||
Comment 45•12 years ago
|
||
Comment on attachment 591428 [details] [diff] [review] (Ev3) (Toolkit, Chrome) test_bug649840.xul: Use window.getComputedStyle() to succeed on XPFE autocomplete too [Test removed in bug 649840] getComputedStyle() would just have been an "even more useless" check: see comment 40 and comment 43.
Attachment #591428 -
Attachment description: (Ev3) (Toolkit, Chrome) test_bug649840.xul: Use window.getComputedStyle() to succeed on XPFE autocomplete too → (Ev3) (Toolkit, Chrome) test_bug649840.xul: Use window.getComputedStyle() to succeed on XPFE autocomplete too
[Test removed in bug 649840]
Attachment #591428 -
Flags: feedback-
Assignee | ||
Updated•12 years ago
|
Attachment #591428 -
Attachment is obsolete: true
Updated•12 years ago
|
Attachment #594474 -
Flags: review?(neil) → review+
Assignee | ||
Comment 46•12 years ago
|
||
Comment on attachment 594474 [details] [diff] [review] (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction [Checked in: Comments 46 and 51] https://hg.mozilla.org/mozilla-central/rev/e12946e259c9 "approval-comm-aurora=?": per comment 39.
Attachment #594474 -
Attachment description: (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction → (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction
[Checked in: Comment 46]
Attachment #594474 -
Flags: approval-comm-aurora?
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
status-seamonkey2.9:
--- → affected
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [perma-orange] → [fixed in SM2.9: Av1, Bv1, Cv1-SM; SM2.10: Dv4] [perma-orange]
Target Milestone: seamonkey2.9 → seamonkey2.10
Assignee | ||
Comment 47•12 years ago
|
||
After bug 649840 comment 55, test_bug649840.xul is removed and the new error is: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1328365017.1328366760.29683.gz OS X 10.5 comm-central-trunk debug test mochitests-5/5 on 2012/02/04 06:16:57 { 9005 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/components/satchel/test/test_bug_511615.html | direction should have been changed from ltr to rtl - got ltr, expected rtl }
Assignee | ||
Comment 48•12 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1328421390.1328422582.22614.gz&fulltext=1 Linux comm-central-trunk debug test mochitests-5/5 on 2012/02/04 21:56:30 { 9097 INFO TEST-PASS | /tests/toolkit/components/satchel/test/test_bug_511615.html | direction should have been changed from ltr to rtl - rtl should equal rtl } V.Fixed
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 49•12 years ago
|
||
Callek, ping for approval. And this is (now) our last aurora m-5 failure...
Comment 50•12 years ago
|
||
Comment on attachment 594474 [details] [diff] [review] (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction [Checked in: Comments 46 and 51] a=me for landing on m-aurora before uplift on tuesday. (Suite Only File)
Attachment #594474 -
Flags: approval-comm-aurora? → approval-comm-aurora+
Comment 51•12 years ago
|
||
Comment on attachment 594474 [details] [diff] [review] (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction [Checked in: Comments 46 and 51] http://hg.mozilla.org/releases/mozilla-aurora/rev/bff5977d29b9
Attachment #594474 -
Attachment description: (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction
[Checked in: Comment 46] → (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction
[Checked in: Comments 46 and 51]
Updated•12 years ago
|
Whiteboard: [fixed in SM2.9: Av1, Bv1, Cv1-SM; SM2.10: Dv4] [perma-orange] → [SM2.10: Dv4] [perma-orange]
Assignee | ||
Updated•12 years ago
|
Whiteboard: [SM2.10: Dv4] [perma-orange] → [perma-orange]
Target Milestone: seamonkey2.10 → seamonkey2.9
Assignee | ||
Comment 52•12 years ago
|
||
http://build.mozillamessaging.com/tinderboxpushlog/?tree=SeaMonkey-Aurora&rev=c821822ca24e m-5 is green (at last) :-) seamonkey2.9: verified.
Comment 53•6 years ago
|
||
Pushed by frgrahl@gmx.net: https://hg.mozilla.org/comm-central/rev/bc127aa3994f (Av1) XPFE autocomplete.xml: Rename openResultPopup()/closeResultPopup() to openPopup()/closePopup(). r=neil. https://hg.mozilla.org/comm-central/rev/d062329d9868 (Bv1) XPFE autocomplete.xml: Rename resultsPopup to popup. r=neil. https://hg.mozilla.org/comm-central/rev/0dc60e044f07 (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction. r=neil. https://hg.mozilla.org/comm-central/rev/a44c609f7f02 (Dv4) XPFE autocomplete.xml: Adjust the direction of the (content) autocomplete popup list based on the textbox direction. r=neil.
Status: VERIFIED → RESOLVED
Closed: 12 years ago → 6 years ago
You need to log in
before you can comment on or make changes to this bug.
Description
•