MozillaZine

Find As You Type Problem

Talk about the native Mac OS X browser.

Moderator: Camino Developers

8-bit

User avatar
 
Posts: 908
Joined: October 19th, 2007, 5:19 pm

Post Posted September 3rd, 2008, 10:36 pm

**** EDIT: See my post below for test casing right on this forum page. Link to external site not necessary so I deleted that info ****
Last edited by 8-bit on September 4th, 2008, 3:13 am, edited 5 times in total.

phiw13
 
Posts: 2777
Joined: November 7th, 2002, 1:00 am
Location: Japan

Post Posted September 3rd, 2008, 11:32 pm

Work fine here (2.0a1pre & 1.6.3). How do you trigger FAYT ? Autostart or using '/' ?

8-bit

User avatar
 
Posts: 908
Joined: October 19th, 2007, 5:19 pm

Post Posted September 3rd, 2008, 11:46 pm

Using "/"

8-bit

User avatar
 
Posts: 908
Joined: October 19th, 2007, 5:19 pm

Post Posted September 4th, 2008, 1:35 am

Test this right on this page: Use '/' and look for edit. Found. Now hit '/' again and try to find "fayt". No go for me - it stops after finding "f". Then the FAYT function hangs - hitting '/' again will not start it back up. Anything that starts with the letter "f" will hang it. If I reload the page I can get the FAYT function back again, but again looking for anything that starts with "f" will hang it.

EDIT: This happens only when I am at the *very top* of the page. Make sure you are scrolled to the top.

EDIT2: Scroll to the top of this page. Hit '/' then "f" followed by any any other character - say "a". It will not let you go any further than "f". However, if you hit CMD-G (find next) TWICE, it will find the "F" in the thread subject header. I don't see any "f"s above that so I am not sure why I need to hit it twice. It will bring back the FAYT feature, and you can find a word that starts with "f", but any subsequent searches beginning with "f" will hang it (it may find one or two and then hang as well)

herbs
 
Posts: 568
Joined: November 22nd, 2003, 8:39 pm

Post Posted September 4th, 2008, 7:19 am

Howdy,

I'm seeing this strange behavior and worse with jcraig's optimized 2.0a1pre build from 02 Sep 08. Not only doesn't the find work pressing / (or almost any other shortcut key, e.g., Cmd-[, rotates the magnification of the page through several iterations.

Good Luck,
Herb Schulz
Good Luck,
Herb Schulz

Euchre

User avatar
 
Posts: 2804
Joined: April 16th, 2006, 12:48 pm

Post Posted September 4th, 2008, 7:46 am

The problem of it becoming tangled up in the magnification is not limited to Camino, it seems to be endemic to all Gecko browsers. I know I experienced it in Firefox 3. I simply used Adblock to remove the text magnification controls from the page and the problem no longer existed. You should be able to achieve a similar effect using userChrome.css.

Edit: Well I thought it was Firefox I had this issue in, but if so it was on Windows. I know I've experienced it and I know I can reproduce it on Camino 1.6.3, and I will check in a bit and see what seems to be the situation under SeaMonkey 1.1.11 on Windows. It may be my Gecko 1.8.x browsers which had this issue, but I'll narrow it when I check those other installs.
Last edited by Euchre on September 4th, 2008, 7:51 am, edited 1 time in total.
Gecko
One Rendering Engine to rule them all.

phiw13
 
Posts: 2777
Joined: November 7th, 2002, 1:00 am
Location: Japan

Post Posted September 4th, 2008, 7:48 am

That is pretty specific to this page, I suspect. A combination of characters/keystroke seems to trigger something similar to accesskey, and then eat ALL keyboard shortcuts. '/edit' then '/fa' triggers that, but '/edit' then '/try' doesn't.

hmm. In the source code:
Code: Select all
<a id="top" name="top" accesskey="t"></a>
<li class="icon-home"><strong><a href="./index.php" accesskey="h">


and then
Code: Select all
<li class="rightside"><a href="#" onclick="fontsizeup(); return false;" onkeypress="fontsizeup(); return false;" class="fontsize" title="Change font size">Change font size</a></li>

Somehow, something sets the focus on the font-resize widget at the top of the page. Then the onkeypress event then swallows everything.

It is late here… I'll leave further debugging to someone else :-)

paulc
 
Posts: 206
Joined: January 5th, 2003, 10:34 pm

Post Posted September 4th, 2008, 7:50 am

Appears the same issue happens when one had FAYT set to auto... repeated the test and it only fins the initially typed "f" and not "fayt" as I tried to input.

Could it be that the issue is that as soon as the first character is typed, it instantly goes off on it's search? Before, it seemed to give the user a second or two before the search was initiated by the app.

phiw13
 
Posts: 2777
Joined: November 7th, 2002, 1:00 am
Location: Japan

Post Posted September 4th, 2008, 8:10 am

Right. The text-resize widgets is a link with this string: 'Change font size'. That text is hidden with a bit of css, but Fayt finds it. That sets the focus on the link, any subsequent keystroke triggers the onkeypress event.

Someone want to go complain in the 'MozillaZine Site Discussion' forum where the guys running this board hang around ? Ask them to nuke that onkeypress thing. Everybody should be happy.

Euchre

User avatar
 
Posts: 2804
Joined: April 16th, 2006, 12:48 pm

Post Posted September 4th, 2008, 11:13 am

I know this issue was mentioned there before, and it didn't get much notice. It appears this is particular to the Gecko 1.8.x builds. I used Adblock Plus' Element Hiding Helper (an addon to the addon) to select the item and write a specific rule to hide that item. This should be resolved with the adoption of Gecko 1.9.x in Camino 2.0, so I'm not surprised that the forum administration is probably not too concerned with making changes to accommodate the older engine. On a side note, this also makes a good point of how easy to use content blocking is more of a tool than just removing visual ads on a page.
Gecko
One Rendering Engine to rule them all.

ishermandom

User avatar
 
Posts: 231
Joined: January 17th, 2005, 7:54 pm
Location: Stanford

Post Posted September 4th, 2008, 11:20 am

Is there any way to configure Camino to bring up the (relatively) new find bar for the '/' shortcut, rather than using FAYT? It would be great to have the behavior that Firefox offers: both '⌘F' and the easier-to-hit '/' shortcuts bound to searching the page with the newer find bar, which seems to be less susceptible to such focus-stealing bugs.

On a related note, if I use the new find bar to search this page for 'fayt', the search doesn't wrap back to the top of the page. Is the cause there the same? It doesn't seem to get stuck in a keypress-eating situation, as you can use '⇧⌘G' to find previous results.

herbs
 
Posts: 568
Joined: November 22nd, 2003, 8:39 pm

Post Posted September 4th, 2008, 2:35 pm

Euchre wrote:I know this issue was mentioned there before, and it didn't get much notice. It appears this is particular to the Gecko 1.8.x builds. I used Adblock Plus' Element Hiding Helper (an addon to the addon) to select the item and write a specific rule to hide that item. This should be resolved with the adoption of Gecko 1.9.x in Camino 2.0, so I'm not surprised that the forum administration is probably not too concerned with making changes to accommodate the older engine. On a side note, this also makes a good point of how easy to use content blocking is more of a tool than just removing visual ads on a page.

Howdy,

I'm seeing this with an optimized Camino 2.0a1pre build. Doesn't that use Gecko 1.9?

Good Luck,
Herb Schulz
Good Luck,
Herb Schulz

phiw13
 
Posts: 2777
Joined: November 7th, 2002, 1:00 am
Location: Japan

Post Posted September 4th, 2008, 4:18 pm

Euchre wrote:I know this issue was mentioned there before, and it didn't get much notice. It appears this is particular to the Gecko 1.8.x builds. I used Adblock Plus' Element Hiding Helper (an addon to the addon) to select the item and write a specific rule to hide that item. This should be resolved with the adoption of Gecko 1.9.x in Camino 2.0, so I'm not surprised that the forum administration is probably not too concerned with making changes to accommodate the older engine. On a side note, this also makes a good point of how easy to use content blocking is more of a tool than just removing visual ads on a page.

Nope, Gecko 1.9 is just as affected by this as is Gecko 1.8. The opposite would have surprised me, given the reason of the problem. And I could repro the issue with Minefield (differently, but still).

Anyway, add the following to your userContent.css, and be done with it:
Code: Select all
@-moz-document domain(forums.mozillazine.org) {
a[href][class="fontsize"] {display:none !important;}
}

That removes the font-size widget from the page.

8-bit

User avatar
 
Posts: 908
Joined: October 19th, 2007, 5:19 pm

Post Posted September 4th, 2008, 5:18 pm

phiw13 wrote:That is pretty specific to this page, I suspect.

It's not quite specific to this page (although I suspect it is the same underlying cause). Here is the original link I had posted: http://mmajunkie.com/ Go there and try this:

  1. Make sure you are scrolled all the way to the top
  2. Type /b (which is the first letter in the headline of the first article as of the time of this post). Nothing - it won't even find b.
  3. Scroll down just enough so that the first line of that headline is not visible and type /evans - this works fine and it will highlight the word in the second line of the headline.
On that page, the fayt feature does not hang, so you can keep trying, but as long as you are scrolled to the very top fayt "breaks".

EDIT: Same on this page: As long as the title header link "Find As You Type Problem" is scrolled off the page, fayt works fine, otherwise it "breaks".
Last edited by 8-bit on September 4th, 2008, 5:41 pm, edited 2 times in total.

8-bit

User avatar
 
Posts: 908
Joined: October 19th, 2007, 5:19 pm

Post Posted September 4th, 2008, 5:22 pm

herbs wrote:Howdy,

I'm seeing this strange behavior and worse with jcraig's optimized 2.0a1pre build from 02 Sep 08. Not only doesn't the find work pressing / (or almost any other shortcut key, e.g., Cmd-[, rotates the magnification of the page through several iterations.

As far as the magnification problem is concerned, do you have a minimum font size set? While trying different things related to the thread topic, I noticed that with a fresh profile I would get the magnification problem. With a minimum font size set, it did not happen.

Return to Camino


Who is online

Users browsing this forum: No registered users and 1 guest