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)

Tracking

(seamonkey2.6 wontfix, seamonkey2.7 wontfix, seamonkey2.8 wontfix, seamonkey2.9 verified)

RESOLVED FIXED
seamonkey2.9
Tracking Status
seamonkey2.6 --- wontfix
seamonkey2.7 --- wontfix
seamonkey2.8 --- wontfix
seamonkey2.9 --- verified

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+
Details | Diff | Splinter Review
11.13 KB, patch
neil
: review+
Details | Diff | Splinter Review
1.15 KB, patch
neil
: review+
Details | Diff | Splinter Review
2.51 KB, patch
neil
: review+
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?
(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: nobody → sgautherie.bz
Status: NEW → ASSIGNED
(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 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+
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 :-)
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)
(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.
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)
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...
Attachment #579493 - Flags: review?(neil) → review+
Attachment #579495 - Flags: review?(neil) → review+
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+
(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
OS: Mac OS X → All
Hardware: x86_64 → All
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).
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)
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 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.)
> (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
(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.
(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.
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)
(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.)
(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 :-|
(In reply to Serge Gautherie (:sgautherie) from comment #22)

(Just in case, should Toolkit autocomplete check for focus like XPFE autocomplete does?)
(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 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 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-
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)
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.
Neil, ping for review. (see comment 29)
Attachment #579206 - Flags: approval-comm-beta?
Attachment #579206 - Flags: approval-comm-aurora?
Attachment #579493 - Flags: approval-comm-beta?
Attachment #579493 - Flags: approval-comm-aurora?
Attachment #579495 - Flags: approval-comm-beta?
Attachment #579495 - Flags: approval-comm-aurora?
Attachment #580311 - Flags: approval-comm-beta?
Attachment #580311 - Flags: approval-comm-aurora?
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]
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]
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]
Target Milestone: --- → seamonkey2.9
Besides tests, what is the benefit for these patches landing on branch?
"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.
Neil, ping for review. (see comment 29)
Priority: -- → P2
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 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-
Attachment #579493 - Flags: approval-comm-beta?
Attachment #579493 - Flags: approval-comm-beta-
Attachment #579493 - Flags: approval-comm-aurora?
Attachment #579493 - Flags: approval-comm-aurora-
Attachment #579495 - Flags: approval-comm-beta?
Attachment #579495 - Flags: approval-comm-beta-
Attachment #579495 - Flags: approval-comm-aurora?
Attachment #579495 - Flags: approval-comm-aurora-
Attachment #580311 - Flags: approval-comm-beta?
Attachment #580311 - Flags: approval-comm-beta-
Attachment #580311 - Flags: approval-comm-aurora?
Attachment #580311 - Flags: approval-comm-aurora-
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.
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)
(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 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+
(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.
Attachment #580311 - Flags: approval-comm-beta-
Attachment #580311 - Flags: approval-comm-aurora-
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)
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-
Attachment #591428 - Attachment is obsolete: true
Attachment #594474 - Flags: review?(neil) → review+
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?
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
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
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
}
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
Callek, ping for approval.
And this is (now) our last aurora m-5 failure...
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 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]
Whiteboard: [fixed in SM2.9: Av1, Bv1, Cv1-SM; SM2.10: Dv4] [perma-orange] → [SM2.10: Dv4] [perma-orange]
Whiteboard: [SM2.10: Dv4] [perma-orange] → [perma-orange]
Target Milestone: seamonkey2.10 → seamonkey2.9
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 ago6 years ago
You need to log in before you can comment on or make changes to this bug.