Closed Bug 295931 Opened 19 years ago Closed 19 years ago

With bfcache enabled, Rocker Navigation extension stops text entry into textarea

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: bugzilla, Assigned: bryner)

References

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050529 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050529 Firefox/1.0+

With the "Rocker Navigation" extension installed (or "All-in-One Mouse
Gestures") and browser.sessionhistory.max_viewers set to 10, it is very easy to
end up in a situation where the Find Toolbar catches arbitrary characters that
the user intends to end up in a textarea.

As with bug 258285, pressing Ctrl+N, then closing the new window works as a
temporary workaround.

Reproducible: Always

Steps to Reproduce:
1. Create a new profile and set browser.sessionhistory.max_viewers to 10 (to
enable the bfcache).
2. Install "Rocker Navigation" from the following location and restart Firefox:
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=677
3. Visit http://www.cusser.net/index.php.
4. Click "Contact".
5. Click inside the message textbox and type "test".
6. Hold the right-mouse-button and left click (navigates back).
7. Hold the left-mouse-button and right click (navigates forward).
8. Click inside the message textbox and type "ing".
Actual Results:  
"ing" appears inside the Find Toolbar, which appears as you start typing.

Expected Results:  
The value "testing" should be entered into the textarea, the Find Toolbar should
not appear.

While using the above steps makes this problem reproducable nearly every time, I
don't think this is an extension related issue. I'm absolutely sure that I've
experienced this without the use of Rocker Navigation or AiO, and in either
case, with bfcache disabled this is not a problem.

This might be related to bug 292977.

Marking major since this completely cripples text entry in some circumstances
(not all of which I can reproduce) and definitely breaks these two extensions
when bfcache is enabled - which is a pity since gestures and rocker navigation
benefit greatly from the bfcache.
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050527
Firefox/1.0+ ID:2005052713

WFM

but is have fayt disabled, fwiw
Sorry, I should have mentioned, this does require FAYT to be enabled as well as
bfcache.
I see this bug by following the reporter's instructions.  I have max_viewers set
to 5, and FAYT on.  I also see bug 258285.

It affects the entire window for me, and I have to open a new window and close
the old one to work around this bug.
sorry for bugspam, that was with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+ ID:2005053115
I see this as well, in fact, fayt can be off and you will still trigger the bug
by typing ' or /. Seems to be a focus problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this (or whatever people see that matches bug 258285 comment 111) all the
time, with Deer Park a1 with fastback enabled.  It's driving me nuts.  We should
get this bug well-assigned.  I'm marking it blocking-aviary1.1+.

Comment 0 talks about rocker navigation, but I don't have that extension
installed and I doubt it is necessary to reproduce the bug that's biting
everyone with Deer Park a1.

/be
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Brenden, I couldn't yet find a reduced testcase for this. I'm sure the extension
is not necessary, but it does cause the problem consistently. It'd definitely be
a nice easy check to see if it's fixed, but probably won't be much use in
finding the cause.
Is this fixed yet?  I'm still running DPa1, can someone who sees this say
whether it happens in the latest builds?

/be
Assignee: nobody → bryner
I can still see the problem
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050626
Firefox/1.0+ ID:2005062607 (Beast)
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Summary: With bfcache enabled, rocker navigation stops text entry into textarea → With bfcache enabled, Rocker Navigation extension stops text entry into textarea
Attached patch possible fixSplinter Review
I was actually looking into a different problem, where focus is lost when using
fastback in Camino, and it occurred to me that it may address this bug as well.
 Basically, I think I want to use the pres shell's CheckForFocus method that is
normally called when painting is unsuppressed.	And really, we can just use
UnsuppressPainting rather than doing the invalidate from docshell.  So I added
this behavior to PresShell::Thaw, with matching code in Freeze to set the
painting-suppressed flag to true so that this can work.
Attachment #187902 - Flags: superreview?(dbaron)
Attachment #187902 - Flags: review?(dbaron)
Attachment #187902 - Flags: superreview?(dbaron)
Attachment #187902 - Flags: superreview+
Attachment #187902 - Flags: review?(dbaron)
Attachment #187902 - Flags: review+
(I'll be curious to see if the SynthesizeMouseMove in UnsuppressAndInvalidate
has any effect on what was in :hover before leaving the page.)
Component: General → History: Session
Flags: review+
OS: Windows XP → All
Product: Firefox → Core
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta3
Version: unspecified → Trunk
Comment on attachment 187902 [details] [diff] [review]
possible fix

a=me for 1.8b3/1.1a2 -- thanks.

/be
Attachment #187902 - Flags: review+
Attachment #187902 - Flags: approval1.8b3+
checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
With the latest Pacifica build, this is still broken for me. Testcase is still
reproducible and I'm getting the less reproducable glitches as well.

browser.sessionhistory.max_viewers = 10

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701
Firefox/1.0+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm still seeing this also.  I'm using AIO gestures 0.16.  Also when this
problem arises I cannot move the caret in textareas with any keys (arrows, home,
end, etc). I think this applies to other form elements too.  

A work around for all of these problems is to enable caret browsing.  Even after
disabling caret browsing things work normally until I gesture or rocker navigate
forward or backward.  (max_viewers is the default value.)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701
Firefox/1.0+ ID:2005070105
Actually it seems to not be caret browsing in particular that can stop the
problem but opening any dialog or window will do.  For example opening the
extension manager and opening the add bookmark dialog also result in behavior
returning to normal.
With a current trunk build, with bryner's fix, I don't see the problem described
in comment 6 and bug 258285 comment 111.  I think that symptom was fixed, or at
least treated.  I do not have Rocker Navigation installed.

Is anyone seeing symptoms described in this bug or in bug 258285 who does *not*
have Rocker Navigation or another (or any) extension installed and enabled?

/be
Brendan: I can't reliably reproduce those problems anyway, so it'll be hard to
confirm.

The only thing I can reliably reproduce is this bug (as filed) with the Rocker
Navigation extension (or AiO), and it is most definitely not fixed. Turning
bfcache off still instantly prevents the problem in comment 0.
(In reply to comment #18)
> Brendan: I can't reliably reproduce those problems anyway, so it'll be hard to
> confirm.
> 
> The only thing I can reliably reproduce is this bug (as filed) with the Rocker
> Navigation extension (or AiO), and it is most definitely not fixed. Turning
> bfcache off still instantly prevents the problem in comment 0.

Ok, thanks -- this bug stays reopened, no objection from me.  I'm just trying to
get more data.  I could reproduce pretty easily in bugzilla form fields, without
any extension, with only BFAYT pref'ed on.

Absence of evidence is not evidence of absinthe ;-).  Still, I would welcome
more data from folks like me who were bugged by (something like part of the set
of symptoms reported in) this bug, who feel no pain now.

/be

Whiteboard: [no l10n impact]
browser.sessionhistory.mav_viewers set to 5 and Mouse Gestures installed, and I
notice it
I can still occasionally reproduce this without the extension installed (it may
or may not be relevent that I'm using an MX1000 mouse with back and forward
buttons). As noted above, the extension is still the best way of reproducing
this bug... I tried, but have been unable to get a better (non-extension) testcase. 
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Alright, I'm getting this bug as well, and it seems to be due to bfcache and
going back/forward.  Period.  When using the superbf thinger, back and forward
will make writeable fields unfocusable.  With FAYT disabled, other keys will
still work (such as ' and / for the find bar) as if you were not focused on
anything but the page itself.

Quick workaround: minimise and restore the page.  For some reason, this will
ALWAYS fix the issue.
I appologize if this isn't the same bug, but I suspect it is, or is related.  I
have bfcache enabled and I consistently see a similar problem.  It seems to
happen most (only?) on sites with frames.

To reproduce:
a) Visit a site with frames, such as http://www.eclipse.org
b) Click a link within a frame
c) Use rocker navigation to go back a page

The result is that I'm no longer able to select text, click on links, or any
other interaction with the page (including further rocker navigation).  Note
that this affects the entire page, not just the frame I went back/forward on. 
It is not fixed by the Ctrl+N suggestion mentioned above, nor by
minimze/restore.  Reloading the page does fix it, however.

Extension I have installed include IEView 1.2.4, DOM Inspector 1.7+, Reporter
1.7+ and Mouse Gestures 1.0.  I'm running the most recent Deer Park nightly.

Again I appologize if this isn't the same bug, but I wasn't able to find a more
specific bug than this.
(In reply to comment #23)
> The result is that I'm no longer able to select text, click on links, or any
> other interaction with the page (including further rocker navigation).  Note
> that this affects the entire page, not just the frame I went back/forward on. 
> It is not fixed by the Ctrl+N suggestion mentioned above, nor by
> minimze/restore.  Reloading the page does fix it, however.

Well, I can confirm this and it looks pretty serious and is bfcache-related, but
it possibly isn't this bug. Anyone else have any thoughts on this?
With attachment 192328 [details] [diff] [review] from bug 258285, this bug WFM. I still see two issues
though (and they probably both need investigation):

The issue in comment 23 - workaround, click outside the window (i.e. desktop) or
minimise, the other as below:

Steps to reproduce:

1. Install "Rocker Navigation" from the following location and restart Firefox:
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=677
2. Visit http://www.cusser.net/index.php.
3. Click "Contact".
4. Click inside the message textbox and type "test".
5. Hold the right-mouse-button and left click (navigates back).
6. Hold the left-mouse-button and right click (navigates forward).

Focus should be in the textarea (as with bfcache disabled). This might need a
new bug, depending on the resolution of this one.
(In reply to comment #23)
> To reproduce:
> a) Visit a site with frames, such as http://www.eclipse.org
> b) Click a link within a frame
> c) Use rocker navigation to go back a page
> 
> The result is that I'm no longer able to select text, click on links, or any
> other interaction with the page (including further rocker navigation).  Note
> that this affects the entire page, not just the frame I went back/forward on. 
> It is not fixed by the Ctrl+N suggestion mentioned above, nor by
> minimze/restore.  Reloading the page does fix it, however.

Look at bug 304288 ...
Was this fixed by the checkin for bug 258285?
Yep. Thanks, Aaron!
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Whiteboard: [no l10n impact]
Component: History: Session → Document Navigation
QA Contact: general → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: