User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041019 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041019 Camino/0.8+ If you load camino with a website that has a text imput field such as www.google.com and then click a link from an external application such as aim the new tab that loads will have the blinking cursor from the first tab. All tabs after this will have this blinking cursor. If you click the first tab and then click the other tabs it goes away. Reproducible: Always Steps to Reproduce: 1.load camino 2.Make sure you have camino as default webrowser and that clicking new links opens new tab. 3.load an app such as aim that allows clicking of a link to send to the browser to open 4.load google as fisrt page or other page that has a text imput field with blinking cursor 5.click a link from external app Actual Results: You will see a blinking cursor in a place that should not be. Expected Results: The blinking cursor should not appear on other pages unless there is a text imput field.
Reporter: Does this also occour with the mac os x version of Mozilla?
Assignee: tabbed-browser → pinkerton
Component: Tabbed Browser → Tabbed Browsing
Product: Browser → Camino
Version: Trunk → unspecified
I'm getting the same thing on the 2004110808 Camino nightly. I have attempted to test this bug on Mozilla but can't work out how to persuade it to open external links in a new tab instead of a new window. Firefox, however, does not appear to have this problem. Bug confirmed, changing status to New.
This bug shows up for me pretty frequently.
Assignee: pinkerton → me
Status: UNCONFIRMED → NEW
Ever confirmed: true
This shows up frequently for me as well, though I can't always reproduce at will. I'm not sure that assigning this to me will help. I spent a little time trying to nuke it when I was putting the original "new tabs" patch together, and I've tried a couple other fixes more recently and not had any luck :-P That said, I do plan to take a swing at this again, but if someone gets to it before I do, by all means take it away from me.
I can pretty reliably reproduce this with the password field of Earthlink webmail <https://webmail.atl.earthlink.net/>, but only after *logging out* of webmail. It doesn't seem to appear when getting ready to log in, or after a failed login, so unless one of the devs happens to have Earthlink email, this is probably pretty not so helpful :(
You are right Aza, that's the same issue. Thnx. *** This bug has been marked as a duplicate of 188517 ***
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Reestablishing the distinction between bug 207210 and bug 188517. See bug 207210 comment 5.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 207210 ***
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.