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)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: bugzilla, Assigned: bryner)
References
Details
(Keywords: fixed1.8, regression)
Attachments
(1 file)
4.37 KB,
patch
|
brendan
:
review+
dbaron
:
superreview+
brendan
:
approval1.8b3+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•19 years ago
|
Blocks: 258285, blazinglyfastback
Keywords: regression
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Comment 1•19 years ago
|
||
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
Reporter | ||
Comment 2•19 years ago
|
||
Sorry, I should have mentioned, this does require FAYT to be enabled as well as bfcache.
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
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
Comment 6•19 years ago
|
||
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+
Reporter | ||
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
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
Comment 9•19 years ago
|
||
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)
Updated•19 years ago
|
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Updated•19 years ago
|
Summary: With bfcache enabled, rocker navigation stops text entry into textarea → With bfcache enabled, Rocker Navigation extension stops text entry into textarea
Assignee | ||
Comment 10•19 years ago
|
||
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.)
Updated•19 years ago
|
Component: General → History: Session
Flags: review+
OS: Windows XP → All
Product: Firefox → Core
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta3
Version: unspecified → Trunk
Comment 12•19 years ago
|
||
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+
Assignee | ||
Comment 13•19 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•19 years ago
|
||
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 → ---
Comment 15•19 years ago
|
||
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
Comment 16•19 years ago
|
||
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.
Comment 17•19 years ago
|
||
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
Reporter | ||
Comment 18•19 years ago
|
||
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.
Comment 19•19 years ago
|
||
(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
Updated•19 years ago
|
Whiteboard: [no l10n impact]
Comment 20•19 years ago
|
||
browser.sessionhistory.mav_viewers set to 5 and Mouse Gestures installed, and I notice it
Reporter | ||
Comment 21•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Comment 22•19 years ago
|
||
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.
Comment 23•19 years ago
|
||
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.
Reporter | ||
Comment 24•19 years ago
|
||
(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?
Reporter | ||
Comment 25•19 years ago
|
||
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.
Comment 26•19 years ago
|
||
(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 ...
Comment 27•19 years ago
|
||
Was this fixed by the checkin for bug 258285?
Reporter | ||
Comment 28•19 years ago
|
||
Yep. Thanks, Aaron!
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 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.
Description
•