An inexplicable Security Warning is reported again on the HTTPS page.

Last month, I tried to handle an inexplicable security warning on an HTTPS page. As a result, I was caught by tester again today. This seems a little more inexplicable than the previous one. Of course, this security warning is also a problem that cannot be reproduced stably. From a specific scenario, it seems that the problem of IE is also a problem of implementation.

The specific error scenario is as follows: the page contains an IFRAME simulated editor. We know that when you press enter, An <p> </P> element is generated by default, by default, all input content is enclosed in the <p> label. When we delete a row in this editor, this editor will also delete the <p> </P> element by default, which seems to be a transparent operation, no problem. However, the problem is precisely due to the default deletion. The following is the part of the Editor:

In this editor, when the cursor is on a line, the line is highlighted. The highlight is implemented by modifying the style attribute of the P element inserted by the editor by default, such as the effect. When moving the cursor, if there is a cross-row behavior, that is, from one P element to another P element, then the element of the original highlight will be restored and the new element of the new highlight will be restored, that is, there is a result of highlight following the position of the cursor. No matter how you move the cursor, there is no problem. But when we use the return key to delete a row, as we just said, the editor will automatically delete the P element of the row to be deleted (in fact, it is removed from the DOM tree ), if we modify the style attribute of the deleted P element again, ie will jump out of the annoying Security Warning window (both IE6 and IE7 have this problem ).

Here, although the element is deleted, ie will cache (keep this element instance) for a period of time by default, so we can still access this deleted element, without running errors. Of course, the elements deleted from the DOM tree also have their own characteristics, that is, its parentelement will be null. In this way, we only need to add the parentelement judgment on the method to cancel the highlight, and modify the resumeline method.CodeIs:

Function Queryeditor. resumeline (line)
{
If (Line && Line. parentelement)
{
Line. runtimestyle. bordercolor='';
Line. runtimestyle. backgroundcolor='';
}
}

Even if this problem is solved in this way, I still feel that this kind of problem is a time bomb that has not been solved by a wave of attacks...