| 2:43 am on Feb 19, 2010 (gmt 0)|
On what browser? I know some mobile browsers don't support them.
| 3:42 am on Feb 19, 2010 (gmt 0)|
One metric might be a look at the number of NoScript downloads for FF. Seems like some installs of IE8 also disable frames (as in iframes, frameset on the other hand works all day long).
| 1:11 am on Feb 20, 2010 (gmt 0)|
By 'web surfers', do you mean desktop users? If so, I can't imagine there being many users that have disabled frames in their browser? How DO you disable frames in the mainstream browsers? (The setting for FF appears to be buried in about:config?)
For other web users, it may be as bill suggests - their browser may not even support them?
| 8:59 pm on Feb 20, 2010 (gmt 0)|
penders, with web surfers I mean people (not bots) accessing websites and viewing them, no matter which operating system, hardware or browser they use.
I have a website with frames. The file with the frameset writes the ip address and the user agent header into a database when it is called. One file within the frameset writes into the database as well, when it is called. It's a little bit more complicated than that, but basically I can see when one visitor called one file without the other. Of course every browser out there can call the framed file without the frameset it is contained in. But to call the frameset without calling the framed files as well you'll have to use a browser that does not support frames (like Lynx) or that does not call them -- by turning frames off.
Now, when I look at my database, I see very many visitors calling only the framset. Some of them are bots (Googlebot, Wget etc.), a few are mobile phone browsers, but quite a few come in with regular versions of IE or Mozilla. So I'm a bit curious about why they don't call the framed file.
If there was one visitor, I'd say that maybe he is using Tamper Data or the user agent header is forged and it is acually a bot, but I get about fifty of these visitors each day. Distinct visitors from widely varying IP addresses.
So I'm curious about what is happening.
| 10:08 am on Feb 21, 2010 (gmt 0)|
|Now, when I look at my database, I see very many visitors calling only the framset. ... So I'm a bit curious about why they don't call the framed file. |
Is it possible that the browser is caching the framed file, but not the frameset?
|If there was one visitor, I'd say that maybe he is using Tamper Data or the user agent header is forged and it is acually a bot, but I get about fifty of these visitors each day. |
| 4:25 am on Feb 23, 2010 (gmt 0)|
All of the individual framed files can appear in the search results, and people can end up calling the framed file without the frameset simply by clicking a result in the SERPs.
I think that would be a more likely scenario than positing that you have such a high percentage of visitors using browsers that don't support frames.
| 6:27 am on Feb 23, 2010 (gmt 0)|
| 8:41 am on Feb 23, 2010 (gmt 0)|
|sonjay: All of the individual framed files can appear in the search results, and people can end up calling the framed file without the frameset simply by clicking a result in the SERPs. |
But the OP appears to be experiencing the exact opposite?!
|manfredkooistra: Now, when I look at my database, I see very many visitors calling only the framset. ... So I'm a bit curious about why they don't call the framed file. |
| 8:52 am on Feb 23, 2010 (gmt 0)|
sonjay, my site is not listed in any search indexes, because robots.txt forbids all robots.
Also, nothing happens, if the framed file is called directly. Let me explain:
This is framset.php. When it is called, PHP writes a "yes" to the database plus the remote address (IP) and a timestamp. Then it outputs the file to the user's browser. The browser then should call the framed file, frame.php, with a timestamp, which PHP inserts into the link, thus: frame.php?timestamp=892349873.
Frame.php, when it is called, recieves the timestamp through GET and looks up the remote address. It then connects to the database and looks for an entry with "yes" which has the same timestamp and remote address (IP) and then updates that entry to "no".
That is all. So every time the frameset is called with the framed file, the entry will read "no". If the framed file is not called, the db does not get updated and the entry remains "yes".
A visitor could call the frameset without the framed file and then call the framed file later, and I would still see a "no". This would happen if a user used Lynx and followed the link in the noframes tag manually. Because it does not matter, how much time elapses between the call of both files.
If a user calles frames.php without the frameset, nothing happens, because there is no entry in the database to update. I won't see this visit in my db.
All I see is if the call to frameset.php is followed by a call to frames.php or not, from the same IP and with the same timestamp.
So if I see "no", it means that frames.php was not called, either because frames were disabled (in a browser) or because the user agent does not support frames (like Lynx or a bot) or because the call to frames.php was aborted by some tool or -- and that is what I'm wondering about -- because there is some flaw in my thinking.
| 8:56 am on Feb 23, 2010 (gmt 0)|
penders, since the framed file is called with parameters, thus: frames.php?timestamp=973498374, the browser should call it again, when it is called with a new timestamp (which is generated dynamically each time frameset.php is called).
I could check for cookies or JS, but I feel I would still wonder about what it all means, because these could be turned on or off in regular browsers as well (and I'm sure that more people consciously control them than control frames, for example I often turn both off when I browse, but I never in my life turned of frames, except to test a page I built for the noframes tag).
| 11:42 am on Feb 23, 2010 (gmt 0)|
Oh, sorry, I misread what was happening as backwards from what's actually happening.
That does seem mysterious. It's hard to imagine that many people surf with frames disabled. What kind of percentage are you talking about?
Do you have a lot of AOL users?
| 12:48 pm on Feb 23, 2010 (gmt 0)|
The code is all serverside (PHP). I have no AOL users at all in the last few days.
And no, I haven't really tested it at all, because I don't have easy access to other computers than my own. But from what I see many "frameless" calls come from systems and browsers like my own (Safari or Firefox on Mac), and the rest are evenly spread about different Windows browsers, so I don't think the "framelessness" is specific to a certain setup.
By the way, the mobile browsers I can identify appear to display frames correctly.
I'll post an extract from the database tomorrow (I flush it every day and it is empty right now) so you can better see what I'm talking about and maybe notice something I overlooked.
Thank you for all your help, so far!
| 1:20 pm on Feb 23, 2010 (gmt 0)|
|I could check for cookies or JS, but I feel I would still wonder about what it all means, because these could be turned on or off in regular browsers as well (and I'm sure that more people consciously control them than control frames, for example I often turn both off when I browse, but I never in my life turned of frames, except to test a page I built for the noframes tag). |
The only thought behind checking for cookies and JS was that if these were disabled when you get a hit to the frameset and not the framed doc then it would perhaps suggest more strongly that these are in fact bots, despite the value in the user agent.
Although, I'm not sure how you can reliably check for cookies/JS with a single server-side request?