Puppy Linux Discussion Forum

Lobster

I have been aware of this for some time - it is now getting annoying and I need it confirmed.

I am using Mozilla and editing the wiki
Using the left arrow key (and sometimes the right) after the smallest edits causes Mozilla to close, shut down,
edits lost.

I have also seen it caused by the delete key. Mostly it is the left arrow key. It seems to be occuring only in the wiki, so I am confident it is a wiki bug and not a Mozilla bug.

Has anyone else noticed this?
Does it happen with Firefox?
Opera?

raffy · Joined: 25 May 2005 Posts: 4812 Location: Manila

The Wiki can do without the editing buttons, after all, it is a Wiki (where formatting is easily done by hand).

In PHP, it is just a matter of removing the Javascript loading lines, and the textarea box will be, well, a plain textarea box Embarassed

Whoever has admin access to the Wikka directory can do that.

(Hey, having some PHP scripting skill is not bad, after all Wink

)

Lobster · Posted: Tue 13 Sep 2005, 05:21 Post subject:

What I mean is when editing code by hand and using the left arrow key to move back across a hand edited piece of text - Mozilla shuts down. If I move using the mouse (my work-around) this does not happen

That is basic editing Smile

Sorry if I was unclear Embarassed

MU · Posted: Tue 13 Sep 2005, 07:01 Post subject:

I cannot edit the WiKi with Mozilla.

Some lines are visible in the first line on over the other (looks garbaged), then there follow some normal lines, and then there are missing the last lines.

I use the Opera(PupGet) instead, works fine.

Mark

Lobster · Posted: Tue 13 Sep 2005, 08:31 Post subject:

Ah yes that reminds me . . .

In Opera (this may be due to strident use of standards by Opera) the wiki does not exhibit the symbols that can be used for editing (at least that is the case in the Opera version available as a Pupget) - is it also true in version 8?

It means that you will not in Opera see symbols to indent text
bold / italic etc - you have to do this by hand . . .

However the bad display is more serious - what is happening?

BarryK · Posted: Tue 13 Sep 2005, 09:41 Post subject:

Lobster, can you try it using the Mozilla in 1.0.5alpha2?
Let me know if the crash still happens.

MU · Posted: Tue 13 Sep 2005, 11:46 Post subject:

Lobster, I used the old opera from Puppy 1.0.4.

Buttons?
I did'nt look for them, I'm too used to <b>bold</b> and so on Wink

Mark

Lobster · Posted: Tue 13 Sep 2005, 11:46 Post subject:

. . . and I thought it was the wiki - it no longer seems to be happening in 1.0.5 alpha r2
- good news. Smile

However the other bug in Mozilla which I have noticed (and others do not seem to have) is still there but it is reduced.

This is what happens in Mozilla 1.0.5 alpha r2. If you click and drag (to resize) Mozilla from the bottom right handle, taking care to click right in the corner - no problem. If you do the same thing but in a bit (to duplicate this effect move out from the center down to the corner - when the icon changes, click and drag. If no jumping upwards occurs (the bug) try again moving in a bit further. If you find the wrong spot (which is the right spot to see the error) the top of mozilla will move up (expand) without you having done anything but click.

I seem to be the only one experiencing this - and I have only just noticed it in 1.0.5 alpha r2 (as it is more subtle). In 1.0.4 I did not bother even trying to click and drag from the bottom right resize handle unless by accident . . .

I am gonna try this on another computer, just to make sure it is not peculiar to this computers graphic chip.

MU · Posted: Tue 13 Sep 2005, 11:53 Post subject:

just tried Mozilla from 1.0.5 alpha2, and everything works ok.

All Text is displayed correctly, the edit-buttons work, and I can use the cursor.keys in the textarea.

Mark

MU · Posted: Tue 13 Sep 2005, 11:57 Post subject:

Lobster, I think the resize-algorithm of Mozilla is somewhat buggy (and damned slow).

So I use the Window-Handles of Icewm to resize.

Extremely fast (as the window-content is not visible during resize, just the border), and works stable.

This is nothing Puppy-specific, I also know this behaviour from Mozilla 1.7 rc2 on Linux Mandrake.

Mark

Lobster · Posted: Tue 13 Sep 2005, 12:01 Post subject:

Just in case anyone is unaware of the edit buttons in the wiki enclosed is a pic.

Double click to open a wiki page (registered users should find the page opens to edit instantly)
Highlight a bit of text make it bold by clicking on bold . . .
click at the beginning of text and indent to move it in etc . . .

Lobster · Posted: Tue 13 Sep 2005, 12:28 Post subject:

OK in 105 Alpha r2 on a different computer with a different graphic chip. Still experiencing problems with that bottom right click and drag handle but they are different. Clicking and dragging now - in the right spot means the resize is not smooth. It sort of judders about. Workable certainly but not smooth.

GuestToo · Puppy Master Joined: 04 May 2005 Posts: 4078

it could be xkb that is doing that
i notice my caps lock/num lock indicator lights don't work properly

and when i edit the wiki, i have to be careful deleting characters, because the auto-repeat does not stop when you release the key ... it stops when you run out of delete characters in the buffer ... and the deletions and moving the cursor left/right with the arrow keys are also slow

i don't think 1.0.3 had this problem
in any case, my keyboard does not work properly with 1.0.4+

see: http://www.murga.org/~puppy/viewtopic.php?t=1380

puppian_guest · Guest

1.0.3 had this problem too
I use 1.0.3 Smile

Would it be that some hotkeys in Mozilla are conflicting with puppy? Just my guess...

BarryK · Posted: Wed 14 Sep 2005, 09:16 Post subject:

Lobster, I just can't get your window-resizing bug.
I've been moving the mouse around in the corner, trying it as you explain, but it works, and is smooth.

Yes, xkb... need to upgrade GTK to a later version that doesn't have the xkb bug, then will be able to turn off xkb support when start X. I should target that one for 1.0.6.