Closed Bug 82151 Opened 24 years ago Closed 23 years ago

Right arrow key at end of a TEXTAREA goes to the beginning


(Core :: Layout: Form Controls, defect, P2)






(Reporter: mpt, Assigned: mjudge)


(Blocks 1 open bug)


(Keywords: polish, regression, topembed+, Whiteboard: EDITORBASE+[adt1])


(4 files, 4 obsolete files)

Build: 2001052115, Mac OS 9.1

To reproduce:
1.  In the `Additional Comments' field in this bug report, enter three or four
    lines of text. (`Lorem ipsum dolor sit amet', copied and pasted several
    times, is always a good standby.)
2.  Place the caret somewhere in the middle of the text.
3.  Hold down the Down arrow key, and watch as the caret comes to rest at the
    end of the text.
4.  Press the Right arrow key, and watch as nothing happens.
5.  Now, enter a few more lines of text, such that the textarea has a vertical
6.  Repeat steps (2) and (3).
7.  Press the Right arrow key.

What should happen:
*   Nothing.

What actually happens:
*   The caret moves to the beginning of the first line of the textarea.

*** This bug has been marked as a duplicate of 80937 ***
Closed: 24 years ago
Resolution: --- → DUPLICATE
verifying duplicate
Bug 80937 has been fixed, but this bug hasn't been -- reproduced on build 
2001052904, Mac OS 9.1. Reopening.
Resolution: DUPLICATE → ---
Verifying on NT 4 sp6, mozilla  build 2001052904.

Now there is a scrollbar, pushing right arrow next and the caret goes to the
-->mjudge since he was in this code recently for some other bugs
Assignee: rods → mjudge
Target Milestone: --- → mozilla0.9.2

simple fix i think good for 9.1 but we can wait for 9.2.
Whiteboard: FIXINHAND
*** Bug 83867 has been marked as a duplicate of this bug. ***
Is this going to get checked in anytime soon ?
Whiteboard: FIXINHAND → FIX IN HAND, need a=
I've seen this bug for the last YEAR or two on Linux builds.  However, until
recently, it would wrap back to the start of the last line, not the start of the
entire text area.  Now that it jumps all the way back to the start, it's quite a
bit more blatent, which is why it seems to have been noticed -- did it really go
unreported for a year or more?

Why didn't I report it, you ask?  (1) It seemed so obvious and basic that
someone must have reported it already.  (2) It's not always easy to find
existing bugs in Bugzilla.  (The Debian bug-tracking system always seemed easier
to use, somehow.)  (3) I didn't want to file a duplicate bug report on something
so obvious.  (There have been cases in the past where I've searched for a bug
yet couldn't find it until my report got resolved as a duplicate -- I'd rather
not create such clutter in the system.)
Blocks: 83989
a= for checkin to the trunk.
(on behalf of drivers)
Whiteboard: FIX IN HAND, need a= → fixed, reviewed, a=asa
*** Bug 85418 has been marked as a duplicate of this bug. ***
*** Bug 85797 has been marked as a duplicate of this bug. ***
its all in
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
This is fixed on build 2001-06-15-08-trunk on Mac OS8.x but I still see this
behavior on build 2001-06-15-08-trunk Linux RedHat 6.2
OS: Mac System 8.5 → Linux
Hardware: Macintosh → Other
Resolution: FIXED → ---
i am at a loss as to why this would be different on one platform or another. I 
will have to find someone with a linux build now.
Hardware: Other → PC
changing whiteboard
Whiteboard: fixed, reviewed, a=asa → NEED UNIX HELP
*** Bug 86312 has been marked as a duplicate of this bug. ***
ok there WAS 1 last thing.  It is the SCROLLBAR that is on by default that was 
causing this to show up on linux only.  once we have a scrollbar on windows the 
same thing happens.

IBMBIDI was behaving oddly and doing some code i was not familiar with.  I added 
a check to NOT execute that redundant code if the frame in question was not 
BIDI. similar check to other places in the app. fixes the wrapping on ALL 
last 2 comments and the patch were done by on kins machine. 
direct all comments to mjudge ;-)
Whiteboard: FIXINHAND → FIXINHAND, need r= and sr= ... FYI the patch mjudge just posted is done with cvs -uw 
the changes you don't see are just indenting existing bidi code so that it lines 
up properly under the 'if' check that mjudge added.
Whiteboard: FIXINHAND, need r= and sr= → FIXINHAND, need r=
Whiteboard: FIXINHAND, need r= → fixed, reviewed, need a=
a= for checkin to the trunk.
(on behalf of drivers)
checked in 
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: fixed, reviewed, need a= → fixed, reviewed, approved
If you put in several lines of text into a text field and a scroll bar appears,
 the problem still occurs on all platforms. Reopening.
OS: Linux → All
Resolution: FIXED → ---
Vladimire is right, I just verified that the 06/19/01 15:04 patch was never 
checked into nsFrame.cpp.
checked into branch and trunk

Closed: 23 years ago23 years ago
Resolution: --- → FIXED
*** Bug 88175 has been marked as a duplicate of this bug. ***
The bug is not completely fixed. The cursor doesnt go to the beginning any more,
but if you go to the end of a text box and press down arrow the cursor will jump
to the end of line and when you press left arrow it doesnt move left.
Expected Results: when you are on the last line and pressing down arrow nothing
should happen like you didnt press the arrow at all. Meaning it should stay in
the same spot, and should be movable. 
Resolution: FIXED → ---
manager reviewed the need for the fix and agrees, approval for checkin to the
trunk and branch after fix has received an r= and sr=, adding nsBranch keyword
Priority: -- → P3
Whiteboard: fixed, reviewed, approved → fixed, reviewed, approved, nsBranch
Target Milestone: mozilla0.9.2 → mozilla0.9.3
If the caret is in the middle of the last line of text, it should move to the end 
of the text (and be movable) on Macintosh if the down arrow key is pressed.  
Similarly, if in the first line of text, pressing the up arrow should move the 
caret before all of the characters.  If there is a problem with this behavior, it 
should probably be filed as a separate bug.

"The cursor doesnt go to the beginning any more" sounds like bug #88164 which was 
fixed yesterday.

I think this bug is fixed so I'm resolving as such; please reopen if you see the 
problems described (not #88164).
Closed: 23 years ago23 years ago
Hardware: PC → All
Resolution: --- → FIXED
Resolution: FIXED → ---
The cursor goes to the beginning on 2001-07-09-05-0.9.2 windows 98 and 
2001-07-09-04-0.9.2 Linux RedHat...
interesting discovery, it seems to only happen the first time that you arrow to 
the end with the down arrow key. If you hit end (after the caret ends back at 
the beginning of the line as mentioned in the steps) and then hit right arrow 
again, nothing happens.

tested this on win98 using trunk build from 7/9/01, removed data from whiteboard
Whiteboard: fixed, reviewed, approved, nsBranch
Bug happens on win98, Mozilla build 2001071214 (trunk). Can reproduce exactly as
originally described, except that at step 4, the cursor may sometimes move to
after the first character of the last line. Also, down arrow is not needed; just
type randomly until scrollbar appears, any moving right or ctrl+right past the
end jumps to beginning of text.
still happening in build id: 20010724-18-0.9.2 in win2000.

over to 9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Occurs in Win2k (at the least) regardless of whether or not there's a scrollbar
when the textarea is defined as "wrap=virtual" (such as on the slashdot site). 
(Build ID 2001080110).
I noticed that this occurs with both right arrow key , as well as, ctrl + right 
arrow key. The cursor keeps looping in the textarea field.

This is not just TEXTAREA! Bug 94119 reports the same problem with inputs that
have size attribute set.
-> 0.9.5. sorry, we can't deal w/ regressions like this right now.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
If this is important to someone for 0.9.5, tell me now so I can find another
owner for it. mjudge won't be back until 0.9.6.
*** Bug 100438 has been marked as a duplicate of this bug. ***
*** Bug 101850 has been marked as a duplicate of this bug. ***
Severity: normal → major
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Keywords: regression
Shift Right Arrow at end of a TEXTAREA selects all the text in the TEXTAREA.
*** Bug 104783 has been marked as a duplicate of this bug. ***
*** Bug 104626 has been marked as a duplicate of this bug. ***
*** Bug 105593 has been marked as a duplicate of this bug. ***
User Agent String: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011
Please note that this is a build from a few nights ago.

I'm still experienceing this bug, and it's really become quite bothersome, as
I've begun submitting more stuff here that requires use of the TEXTAREA,
resulting in this bug bothering me more the more bugs I report. FIX IT ALREADY!
Sorry, that was uncalled for.
Lorem ipsum dolor sit amet steps are works for me on Linux, at least, to my
naive eyes the cursor movement with arrow keys as reported originally works
fine. Can someone post some steps that illustrate this problem (or close the bug
if it really doesn't exist?)

I see the problem with the original steps to reproduce:

1)  put one char on each line of the textarea, hitting enter after each one till
    the scrollbar appears.
2)  hold down the right arrow key and watch the cursor loop.

This is with a 2001-11-02-08 build.
No longer blocks: 83989, 108120
adding back dependencies that went away for some reason...
Depends on: 83989, 108120
No longer depends on: 83989, 108120
*** Bug 108818 has been marked as a duplicate of this bug. ***
Whiteboard: EDITORBASE
noticed that the looping with 
1. right arrow 
2. ctrl + right arrow 
only happens if the vertical or horizontal scroll bars appear in the textarea.
*** Bug 109845 has been marked as a duplicate of this bug. ***
*** Bug 110192 has been marked as a duplicate of this bug. ***
0.9.6 is gone -> 0.9.7 
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** Bug 94076 has been marked as a duplicate of this bug. ***
*** Bug 111286 has been marked as a duplicate of this bug. ***
*** Bug 112164 has been marked as a duplicate of this bug. ***
This bug has 16 duplicates.  Doesn't it deserve "mostfreq" status yet?
and 19 votes... pushing it into the "nagging users" category :)
There's no "mostfreq" keyword anymore, see Most frequently reported bugs
page is updated automatically. This bug is already listed there, thus no need
for complaints here.
Nominating for nsCatFood based on keywords thingie :-)
Keywords: nsCatFood
*** Bug 115653 has been marked as a duplicate of this bug. ***
There are other caret-at-end-of-textarea misbehaviours too. This is in Mac build

1. Type a few lines into a textarea.
2. Place cursor in the middle of last line.
3. Press down arrow key to move caret to end of last line.
4. Press right arrow key.

Expected result: Nothing.
Actual result: Caret moves to 2nd positon of last line.

Also try:

4. Press left arrow key.

Expected behaviour: Caret moves 1 step left.
Actual: Caret moves to end of above line.

So it's obvious that Mozilla displays the caret at end of text, but treats it as
at beginning of last line.

Here's another one:

1. Type a few lines in a textarea.
2. Place a newline at end of last line, creating an empty line.
3. Place cursor in the line above and press arrow down key.
4. Press arrow down key again.
5. Press arrow down and hold.

Expected behaviour: Nothing.
Actual: At (4), caret jumps to end of line above. At (5), it cycles between
those two positions.
Wait, Travholt.
your bugs of comment #67 are different from original reported bug, I think.
Because original bug occur only after scrollbar appeared.
bugs of comment #67 always occur.
see  Bug 113260 and Bug 106855.
Argh, this bug has plagued me for years. With every version of Mozilla, as it
was downloading, I'd say to myself "Surely, THIS version must fixt the textarea
cursor issues." I don't have anything else to add, I'm just complaining.
This doesn't seem to require a scrollbar--I can do it with a single line of
text.  And it doesn't always seem to be the beginning of the line; try this:

1. Enter some characters ("abc" will do) in the bottom line of a textarea.
2. Press down arrow.
3. Enter some more characters ("xyz").
4. Press down arrow.
5. Press right arrow.

The caret moves to after the "x".  (Pressing Left instead moves the caret before
the "c".)
Noble target, but you might want to bump it up two notches. Does this bug also
cover the issue of 'down arrow, LEFT arrow' moving to the end of the line above
the last?

I should also mention I see the cursor move 1 pixel left often when I hit down
arrow on the last line. Seems to occur more often after typing an 'e'. Pressing
the 'end' key moves it 1 pixel back to the right. I can continually press
down/end/down... and watch the cursor jump back and forth 1px.
Keywords: mozilla0.9.7
Adding more reasonable nomination.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Blocks: 115520
Note that there is a patch in the bug 106855 which maybe could fix this bug.
Depends on: 106855
See also bug 103039 "Line editing in text entry boxes messed up".
Blocks: 103039
To reproduce:
1.  In the `Additional Comments' field in this bug report, enter three or four
    lines of text. (`Lorem ipsum dolor sit amet', copied and pasted several
    times, is always a good standby.)
2.  Place the caret somewhere in the middle of the text.
3.  Hold down the Down arrow key, and watch as the caret comes to rest at the
    end of the text.
4.  Press the Right arrow key, and watch as nothing happens.
Hoppla... Sorry for the spam... :(
*** Bug 94119 has been marked as a duplicate of this bug. ***
*** Bug 93399 has been marked as a duplicate of this bug. ***
*** Bug 94673 has been marked as a duplicate of this bug. ***

curious, I dont see mention of driver approval yet for this on the branch.. let
alone bug 106855.  Someone added it to the dependency for 0.9.8.
*** Bug 122556 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
No longer depends on: 106855
To make it clear what's the real issue.
The various behaviours described in comments 70, 75 and maybe others are fixed
by the patch to bug 106855.
But the originally reported behaviour (the same as comments 52, 55) is not fixed
by the patch.
Blocks: 124140
nsbeta1+ per ADT triage team
Keywords: nsbeta1nsbeta1+
editorbase+ per meeting
Priority: P3 → P2
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Blocks: 93192
Comment #82: Tom, the issue in comment #70 is not fixed by the patch either.
It's still reproducible in Mac build 2002021208. However, it's just in the first
line. It's a minor bug, but it's still a bug. :-)

Upon checking out this, though, I found ways to reproduce another one, which I
haven't seen reported anywhere, so I'll report it now.
(These last two paragraphs are written to check the effects of that bug.)
I found very instructive test cases.
Please check two test cases below.

I confirmed on 0.9.8/Linux and 2002021621/Linux.
This test case is no problem.
and Right-arrow cause nothing special.
This test case is almost same with one above.
But there is some magic. :-)

This test case gives you some insight, probably.
Sorry, two test cases have a mistake like:
It should be

Even if you fix them, these test cases are significant.
Keywords: topembed
*** Bug 115211 has been marked as a duplicate of this bug. ***
I filed comment 70 as Bug 127554.
and I wrote a patch to fix the bug.
Attached patch a patch for nsLeafIterator (obsolete) — Splinter Review
I tried to write a patch.
And this is the result.
This patch fixes Bug 93192 also.

It prevents nsLeafIterator::Next() and Prev() from ascending parent Frames
above "scrollFrame".
I don't know much about whether this is a good way or not.
Comments welcome.
Keywords: topembedtopembed+
Keywords: patch, review
still see this happening on win2000 03-07-10trunk build
refer to my comment #55
No longer blocks: 103039
removing myself from the cc list
got same bug on nt4.0 sp5, mozilla 0.9.9 build 2002031104
would even be okay if you could get back to the end with the left-arrow-key,but
that's blocked!
still see it happening with yesterday's nightly on mac os 9.2
CCing jfrancis as he works on other textarea bugs too.
Please look at the patch if you can...
In the second patch, if you are going to check for a null frame state, you should 
initialize it to zero.  There is no nsFrameState constructor to do this for you.

The selection changes look ok.  I'm really not well qualified to evaluate the 
Target Milestone: mozilla0.9.9 → mozilla1.0
No longer blocks: 115520
restoring dependency.  Please do not remove dependencies without good reason 
(they denote a lot more than "this bug needs to be fixed to fix that bug")
Blocks: 115520
Whiteboard: EDITORBASE+ → EDITORBASE+[adt1]
if we hit a scrollable view. sometimes we need to stop. (i.e. edit box/ text
area)  If we have a limiter on selection then play it safe a stop iterating
when we hit a scroll view.  more complicated than the last patch but allows us
to jump out of scrollable frames in the case of say a scrollable table cell or
something like that.
Attachment #71446 - Attachment is obsolete: true
Comment on attachment 77364 [details] [diff] [review]
regulates when we stop when we hit a scrollable view in the frame tree

-- Need to remove one of these duplicated statements in nsLeafIterator::Next():

	       parent = result;
    +	       parent = result;

-- Do you really want to check in the #ifdef/#endif DEBUG_skamio printfs? If
so, lose the spaces before the #, I seem to remember some compilers choking on
that in the past, but things may be different now.

-- You do this casting of (PRBool)mLimiter in 2 places in nsSelection.cpp:

     + pos.SetData(mTracker, desiredX, aAmount, eDirPrevious, offsetused,

   please change them so that a real PR_TRUE or PR_FALSE value is used, for
example use:  mLimiter != nsnull

-- Why do the SetData() calls in nsFrame::PeekBackwardAndForward() hardwire the
aScrollViewStop arg to PR_TRUE? Shouldn't they ask the selection if it has an
mLimiter and base what it uses on that?

-- Please add spaces between the "," and what you added in these portions:

    -	  aPresContext, resultFrame);
    +	  aPresContext, resultFrame,aPos->mScrollViewStop);

    -	  : traversedFrame);
    +	  : traversedFrame,aPos->mScrollViewStop);

    -  result = NS_NewFrameTraversal(getter_AddRefs(frameTraversal),LEAF,
aPresContext, traversedFrame);
    +  result = NS_NewFrameTraversal(getter_AddRefs(frameTraversal),LEAF,
aPresContext, traversedFrame,pos->mScrollViewStop);
removed extra line.
removed extra spaces.
removed #'d for debug statements.
changed prbool casting

peek backward and forward is used for jumping words or paragraphs.  the 
paragraph in my mind is good to stop on a scrolled view. (i.e. tripple click 
and dont select out of a scrolled view).  Also there is no current way to go 
from nsISelectionController to get the limiter.  nsISelectionController has no 
such concept.  I think some QI work could go into getting the nsIFrameSelection 
to then get the limiter and if one exists to then pass in the parameter 
properly, but I dont see the reward for the extra complication since its not 
really necessary in that case.
see above comments
Attachment #77364 - Attachment is obsolete: true
Comment on attachment 77946 [details] [diff] [review]
fixed small things from kin's comments

This isn't the entire diff of all your changes, but answered my one question
above, and this change was the only one I was concerned about.
Attachment #77946 - Flags: superreview+
this is since jfrancis is unavailable for r= on new bug i am posting full new
diff for someone else to review.
Attachment #78272 - Flags: review+
Confirming patch 78272 works on linux. Any chance of getting the patch onto the
branch? Looks like just a= is needed from the attachment status above, but the
comment below looks like r= is still needed as well??
Comment on attachment 78272 [details] [diff] [review]
full patch including change for kin.

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #78272 - Flags: approval+
adding adt1.0.0 nomination
Keywords: adt1.0.0
Pls check this into the trunk for a couple of days, and have QA verify that the
patch resolves the issue, and does not cause any regression.
Red Hat Bugzilla equivalent to this bug   
Red Hat mozilla- merged with this patch. 
I manually merged "full patch including change for kin." with Red Hat's   
mozilla-0.9.9-7.src.rpm and have been tested it for a day.  I have found that it fixes  
most of this bug but with one exception.  If you scroll all the way down with the down  
key so that the cursor jumps beyond the final character, the right key makes the cursor  
jump to the beginning of that line. 
I suspect that this other behavior is due to another bug fixed since 0.9.9.  Is this the  
What version of Mozilla should I merge the full patch above with in order to do proper 
i have this patch applied to latest trunk and I cannot reproduce the problem 
you are seeing.  
Either A) I am not doing the right thing in which case I would like exact steps 
to reproduce or B)  This was fixed by some other but patch.  

I am hoping for B but I would like you to really spell out what you did to 
cause the caret to move to beginning of line.

Were you in composer or a text area, what to type in ect.

Thanks a lot.
I just tested nightly 2002041510.  It worked properly in that build, so the
"right key going to beginning of line" must have been another patch.

Any idea which patch this was?  I hope these fixes can make the next Red Hat
mjudge: you caused bustage on Ports. please fix it.
1018926840, Linux myotonic Clobber
Build Error Summary
C  -I/usr/X
gmake[6]: *** [nsFrame.o] Error 1

/builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp: In method `nsresult nsFrame::GetFrameFromDirection(nsIPresContext *, nsPeekOffsetStruct *)':
/builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: `pos' undeclared (first use this function)
/builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: (Each undeclared identifier is reported only once
/builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: for each function it appears in.)
/builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3850: warning: unused variable `struct nsRect testRect'
gmake[6]: *** [nsFrame.o] Error 1
i changed pos to aPos. I'm watching myotonic. Matti also hit this (gmake, windows, disable bidi)
in trunk.  hmm i will look at patch to see how i messed that up for ports. 
sorry about that. Thanks for fixing it!  Warren could you test the 1.0 branch? 
see if the beginning of line is fixed there before I land this patch on it?

P.S. sujay please test this;)
I feel compelled to point out that --disable-bidi is NOT a very healthy
configure option to be using.
See bug 89203 (and 88509 and 86517 which inspired it) for the discussion
to remove it alltogether.
Changing qa contact, Mike I'll test on branch and get back to ya
QA Contact: vladimire → tpreston
Terri - You mean to test this on the trunk, right? This is not on the branch yet.
This is fixed using win XP trunk build 2002041603 Mac OS X trunk build
2002041603 and linux trunk build 2002041609
adt1.0.0+ plesase checkin to branch asap and add keyword fixed1.0.0
Keywords: adt1.0.0adt1.0.0+
*** Bug 138013 has been marked as a duplicate of this bug. ***
adding fixed1.0.0 and marking fixed
Closed: 23 years ago23 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
*** Bug 139133 has been marked as a duplicate of this bug. ***
Verified fixed Win 2k branch build 2002042203, Mac OS X trunk build 2002042205
and linux trunk build 2002042208
Verified fixed Win 2k branch build 2002042203, Mac OS X trunk build 2002042205
and linux trunk build 2002042208
Keywords: verified1.0.0
Common case fixed, uncommon case still buggy:

Open a Yahoo or Hotmail Mail account.  Recieve some mail.  Select "reply" so
that the mail gets quoted in the main textarea.

Now hold down "Ctrl" and move the arrow forward so that the caret skips one word
at a time (as it should).  At the end of the textarea, the caret will still wrap.
I reproduced what Soren Ragsdale described, but with one exception. Wrapping
only occurs when there is a scrollbar present. (Mozilla 1.0 Release Candidate 1,
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020416)
Should this be a new bug since it includes the control key?

While I tested this I found another oddity control and left arrow does no reach
the first empty rows. 
To reproduce: Press enter a few times in the additional comments field in
bugzilla. Then enter some text. Use control-left arrow to go back to beginning.
Expected result: Caret should reach beginning of the first line.
What happens: Caret stops at the beginning of the first line to have text in it.

I filed this as a new bug (139402) since it isn't in the depends list of bug 108120.
*** Bug 140739 has been marked as a duplicate of this bug. ***
*** Bug 148150 has been marked as a duplicate of this bug. ***
*** Bug 114937 has been marked as a duplicate of this bug. ***
Attachment #36557 - Attachment description: save member variable to temp and wait for success to save → save member variable to temp and wait for success to save [Checked in: Comment 14]
Attachment #36557 - Attachment is obsolete: true
Attachment #39198 - Attachment description: fix to check for bidi on frame → fix to check for bidi on frame [Checked in: Comment 25]
Attachment #39198 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.