The Five Minute Time Limit to Edit Posts

I don’t think he’s saying that if you open an edit window, you can always post from that edit window. Rather, the first time it would work as normal, but if the 5 minute window has expired, the edit button shouldn’t work.

The problem is that the edit feature built into the software doesn’t check the time limit. If the edit button is on the screen, it pulls up an edit window. The software check will disable the edit button so it does not appear, but if you have a cached page with the edit button showing, that edit button will work. However, when the system tries to load the page, it verifies the time limit and rejects the post.

Unfortunately, this is a feature of the way vB coded the site, and there is nothing that the Straight Dope can do. Feel free to go to vB website and post your comment there; it may already be a topic there, as we are running a version of the software that is several versions old. We’re running vB 3… and it’s currently up to vB 5… or 6… or whatever.

Back in ancient times, I was connecting via a phone line with a flaky connection (an alarm installed in my apartment but not monitored was hijacking the phone line), I did a lot of composing in notepad for this very reason. That way, my post was cached somewhere. Now I rarely lose a post completely, and sometimes the back button saves a copy. Theoretically, you are correct that it is marginally better from a redundancy standpoint to compose and edit in a separate program, then copy/paste to the edit window and give one final preview pass. However, practically, the marginal gains are – most of the time – not worth the hassle.

But I’m disappointed that neither of you mention this procedure that seems kind of “unfortunate” to me - which is even when the five minute clock has expired, you can still hit “Edit” and the board software will permit you to spend time editing your post. But then, when you hit “Save” it will tell you the time is up.

If the time limit has not expired, the button works. If the time limit expires while you are composing the message, the post will not load. If you use a cached copy of the page that has the edit button, how does the software know that? That is a feature of how vB works and is not something that can be configured by the SD.

I suspect some of what happens with edit windows and back buttons and caching content is browser dependent behavior.

Okay, Experiment #2: Similar to Experiment #1 as in Post #19 above, but with JavaScript ENABLED this time.

NOW, I get the same results that everyone else here is talking about, as shown in Joey P’s screen shot.

Here is my screen shot of this. Here, I’ve highlighted a portion of edit window text. I had a right-click menu too, but when I take the screen shot, that disappears.

We note, first, that the edit window appears and allows me to type my edit even though the time limit has long since expired before I clicked the Edit button in the first place! This is some seriously stupid behavior. I’m going to call it an outright bug, inasmuch as I can’t see any useful interpretation for this behavior. This is clearly the behavior under discussion in this thread, as described by OP Charlie Wayne in the first place. (Are you still with us, OP?)

Second, we note that my message box is positioned right smack in the middle of the message, somewhat differently from Joey P’s pic. This no doubt is just a matter of local screen sizing details, and isn’t significant. Except it makes it really hard to capture just a part of the text I want, if that text is behind the message box. In my pic, I’ve highlighted a portion of text to copy. This works if the start and end points of the desired text are visible. If not, I would have to capture more and edit it later.

Third, we note that the message box, at least as seen in my browser, is not movable! I can’t drag it to somewhere else on the screen in order to uncover a hidden portion of the text that I would like to copy. This, again, is some stupid vBulletin behavior. (More specifically, I assume that this behavior is programmed into the JavaScript embedded in the page.)

It’s not Linux or the older Firefox that’s causing these differences. It’s the behavior of vBulletin when JavaScript is enabled vs. disabled on the client. It’s certainly possible to code a web site that behaves differently with and without JS – many sites do this. The desired goal is to create a site that works well and full of fancy-schmancy stuff with JavaScript, yet still provides the basic required functions properly without it. (Gmail, for example, does this nicely.) vBulletin seems to have goofed: They made one feature here that works better without JS than with! Oops!

ETA:

Well, maybe, but I kinda doubt it, at least in the situations we are discussing here.

More ETA :

Uh, I think that what this whole thread has been talking about, isn’t it?

Thanks for tracking that down. It seems to explain the differing results pretty well. Not sure what the javascript is doing, but clearly it would be better if it always checked the timestamp before rendering the edit window.

It wouldn’t solve the problem of someone opening an edit window before the 5 minute timer expired and not finishing their edits until after, but it’s a start. Have you looked at the vBulletin boards to see if this is addressed?

My WAG for not being able to move it is that it’s not actually a Window in the typical sense of Windows. It’s just some sort of graphic that VB is tossing up. As for the location, I think you’re right about screen size/resolution etc. Sometimes mine is right over the text as well.
If it’s really an issue, you could just right click anywhere in the box, click ‘select all’ then copy and you’d have everything to edit later.

I think the error-message window is an actual Windows window, although with some unusual properties. I’ve done a bit of programming of that sort. Even “normal” windows have a variety of attributes that can be specified when they are created, with defaults that give normal-looking windows. These properties include:
[ul][li] Border: A window can have a “thick” border (the default; you can point your mouse at any border and drag it to re-size the box); “thin” border (border is just a thin line; you can’t point-and-drag the border to re-size); or no border at all.[/li][li] Title bar: The title bar can be present or absent. If present, you can drag it to move the whole window. If absent, you can’t.[/li][li] If title bar is present, you can select which of the normal buttons will be there. (Note for example that the button with the ? symbol is present in some windows but not all.)[/li][li] The window can be set to be “always on top”, in which case a window behind it cannot be brought forward on top of it. That’s why you can click on the edit box behind it and select text there, yet the edit box does not come to the front. (For another example, look at the Windows Task Manager, at least in Win XP. There is an option “Always on Top” in one of the menus that does this.)[/li][li] Numerous other properties can be specified, with various effects.[/ul][/li]
Note that the time-out message window has a gray bar across the top that vaguely looks like a title bar, but it isn’t really at all. It’s just a gray rectangle drawn at the top, just as the purple bar at the bottom is just a rectangle drawn there. (Yes, I’ve made multi-color windows with tricks like this too.) Note the “X” button in the upper right doesn’t look like a normal “X” button. I think it’s actually just an ordinary clickable button with an X on it. Also, note the underlined word “administrator” is clickable, as is the word “Cancel” at the bottom. If this window were just a graphic, it would take extra work to have clickable controls in them like that.

I think it’s just a normal Windows window with some non-default and poorly thought-out attributes set. The main bug is that you are allowed to open the edit box in the first place after your time is up. I just can’t see any reason why that would be a useful thing.

As for the other problem: You start editing while you still have time, but run out of time while you edit (but you don’t know that) and then get dinged when you click on “Save”. You can save your work as Joey P says. (Hint: You can also select all by typing Control-A in most browsers.) It would be nice to have a live count-down timer somewhere in the edit window. I’ve programmed windows with live visible count-down timers too, so I know it’s doable. But you would need JavaScript enabled for it to work.

Sorry, I mangled my quote editing. That comment was actually a line from Charlie Wayne that I didn’t get edited out of my post.