Internet Explorer 6 and 7 fails with four or more of the buttons on the graphical markup toolbar: de-selection of text seems to be common

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Internet Explorer 6 and 7 fails with four or more of the buttons on the graphical markup toolbar: de-selection of text seems to be common

Graham Perrin
This post was updated on .
Internet Explorer 7, Windows XP.

1. in the midst of a message composition window, select some text

2. click the Link button

3. follow the IE prompt to Temporarily Allow Scripted Windows; click the drop-down

4. observe the loss of selection in the dialogue

5. re-select the text

6. click the Link button

7. in the dialogue, complete the URL

8. key Enter

9. observe persistence of the dialogue

10. again, key Enter

Bugs

IE 7 requirement to repeatedly allow scripted windows is a PITA, maybe there's a Microsoft user preference to reduce this annoyance.

Responding to Microsoft's scripted window dialogue (drop-down) should not de-select text that was previously selected.

The dialogue in which the http:// URL is entered should close in response to the first press of the Enter key.

The selected text (in the midst of the text editing area) is not marked up.

The twice-entered link appears twice, away from the selected text — beginning at character position 1 of line 1.

The i-beam cursor rests between (a) the second entry of the hyper-link and (b) the character that was previously at character position 1 line 1.
Reply | Threaded
Open this post in threaded view
|

Internet Explorer 6.0.app (ies4osx in Darwine) crashes whilst loading http://n2.nabble.com/

Graham Perrin
This post was updated on .
This crash may be due to incomplete IE/Darwine support for ActiveX. That's a guess.

I don't assume a bug with Nabble, but it's timely to note the symptom.

Source of this particular IE 6 installation: ies4osx.

Postscript: Internet Explorer 6.0.2800.1106 does not crash in CrossOver. Within this topic, this particular message may be negligible.
Reply | Threaded
Open this post in threaded view
|

Internet Explorer 6.0.2800.1106 bugged behaviour is similar to that of IE 7

Graham Perrin
Graham Perrin wrote
IE 7 requirement to repeatedly allow scripted windows is a PITA, maybe there's a Microsoft user preference to reduce this annoyance.

Responding to Microsoft's scripted window dialogue (drop-down) should not de-select text that was previously selected.
Internet Explorer 6.0.2800.1106 in Crossover 7.1 (7.1.0) on Mac OS X 10.5.6 presents buggy behaviours comparable to Internet Explorer 7.

The ActiveX and Temporarily Allow Scripted Windows interruptions do not occur. Whether this is thanks to the absence of Internet Explorer 7, or thanks to the Wine-based installation (absence of Microsoft Windows), I don't know.



This message with attachments and formatting sent using Internet Explorer 6.0.2800.1106 in CrossOver for Mac OS X.
Reply | Threaded
Open this post in threaded view
|

Re: Internet Explorer 6 and 7 multiple failures with bold, italic and Link features of the graphical markup toolbar

Graham Perrin
In reply to this post by Graham Perrin
Graham Perrin wrote
The dialogue in which the http:// URL is entered should close in response to the first press of the Enter key.



The twice-entered link appears twice, away from the selected text — beginning at character position 1 of line 1.
Please: ignore those aspects of the bug report. I was not paying attention.

The first press of the Enter key enters the underlying link.

The second press of the Enter key enters the overlying, visible linked text. (This is, I guess, a side-effect of the de-selection of previously selected text, an apparent jump of the i-beam to top left within the editing area.)
Reply | Threaded
Open this post in threaded view
|

Re: Internet Explorer 6.0.2800.1106 bugged behaviour is similar to that of IE 7

Graham Perrin
In reply to this post by Graham Perrin
I selected the second sentence before clicking the Link buttonLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrI selected the word 'nostrud' then clicked the italic button. ud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. ExI selected the ultimate paragraph then clicked the bold button.cepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Reply | Threaded
Open this post in threaded view
|

Re: Internet Explorer 6.0.2800.1106 bugged behaviour is similar to that of IE 7

Graham Perrin
Focusing on my use of Internet Explorer 6.0.2800.1106 for the preceding example:

• a manually entered link is misplaced at the beginning of the text editing area

• an image is misplaced at the tail of the text editing area

• manually entered italic text is misplaced in the midst of the previously selected word, between the fifth and sixth characters of a seven-character word (I paid no attention to whether Windows/IE selected the white space beyond the word before clicking the italic button)

• manually entered bold text is misplaced in the midst of the previously selected sentence, following the second character of the previous selection.

De-selection of text seems to be common.

Placement of the subsequent entry varies.
Reply | Threaded
Open this post in threaded view
|

Re: Internet Explorer 6.0.2800.1106 bugged behaviour is similar to that of IE 7

Hugo <Nabble>
We have fixed this bug.
Please try again and let me know if you still see this problem.

Regards,
Hugo Teixeira
Nabble.com
Reply | Threaded
Open this post in threaded view
|

Insert Image button: result is misplaced at the tail of the text editing area

Graham Perrin
Hugo <Nabble> wrote
Please try again and let me know if you still see this problem.
Mostly fixed, thanks.

Still bugging Internet Explorer 6.0.2800.1106 in CrossOver
(not bugging Safari 3.2.1 (5525.27.1)):

> an image is misplaced at the tail of the text editing area