8000 Right click doesn't offer paste at empty prompt · Issue #37 · hostilefork/replpad-js · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Right click doesn't offer paste at empty prompt #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
hostilefork opened this issue Mar 28, 2019 · 13 comments
Open

Right click doesn't offer paste at empty prompt #37

hostilefork opened this issue Mar 28, 2019 · 13 comments
Assignees
@hostilefork @BrianOtto

Comments

@hostilefork
Copy link
Owner
hostilefork commented Mar 28, 2019 •
edited
Loading

UPDATE: This question asks the exact thing, and explains that we don't want solutions that force the input to become block or inline-block. Everyone who suggests float: left etc. seems to not understand that flowing/wrapping behavior is desired as well as making the element subsume the width.

https://stackoverflow.com/questions/11572905/min-width-on-inline-not-inline-block-behaving-element

"Every solution I've seen uses inline-block, but I can't use inline-block behavior. When inline-block starts wrapping, it still behaves like a block element, and I need the div to behave as an inline element." Yes, exactly.

This also relates:

https://stackoverflow.com/questions/48849055/how-to-make-an-inline-block-element-span-the-rest-of-the-text-line

I added a couple of hooks to strip off formatting when pasting text into the ReplPad, or when copying text out of it:

39d2660

That's a welcome improvement! But while trying it out I noticed that right clicking in an empty prompt doesn't offer the usual text-insertion option of pasting text. It makes the cursor vanish and offers different options like viewing source or saving. So not a "quick edit" menu--or whatever you call it.

But typing text and putting the cursor in the middle of it gets the right menu.

I think this pertains to the idea that right clicking does some of the normal click logic first, and then the oncontextmenu event after that. There's currently a bit of a tapdance to get it to position the cursor in the right place at all based on clicking in the big empty space...and I'm sure I'm probably doing that wrong.

So this is probably suggesting a closer look at why the juggling is needed in the left click case; and if that weren't needed, it might make the context menu just work. Otherwise it might be necessary to mirror some of the logic to be focused on the right place in the oncontextmenu event.
@gchiu
Copy link
Collaborator
gchiu commented Mar 28, 2019 via email

@BrianOtto
Copy link
Collaborator
8000

I have been looking into this, and I'm pretty sure it is related to the comments I posted in #38

The context menu doesn't appear because the div is empty, and so there is no selection range in which to trigger it. If I add padding-left: 20px to the .input CSS, and click within the padding, the context menu will appear.

Still looking into workarounds ...

@BrianOtto
Copy link
Collaborator
BrianOtto commented Apr 1, 2019 •
edited
Loading

It appears like changing the input <div> to a <textarea> will fix the issue, and then you can get rid of all that messy contenteditable handling. The <textarea> border can be hidden, and it can also be made to grow in size as you type. I have something working locally that appears to do the same job as the <div>.

Unless you can think of a specific reason why contenteditable is needed, then I'll start putting my changes into a new branch and you can try it out there.

@hostilefork
Copy link
Owner Author

Unless you can think of a specific reason why contenteditable is needed, then I'll start putting my changes into a new branch and you can try it out there.

I was trying to leave the door open to things like syntax highlighting as you input, or automatically hyperlinking links, or things like that.

As far as I know, a textarea can't do any of that, so I was looking to work from a foundation that would allow it.

@BrianOtto
Copy link
Collaborator

Oh, I see. Yea, a textarea won't give you that. I'll keep looking into a contenteditable solution then.

@BrianOtto BrianOtto mentioned this issue Apr 5, 2019
Merged
@BrianOtto
Copy link
Collaborator

I have found a working contenteditable solution. Please see PR #40

@hostilefork
Copy link
Owner Author

Great! I can now accomplish a paste from a right click! Definitely an improvement over not being able to. :-)

It's still a pretty narrow space. Looking at the element layout with the "hover and inspect" tool, it's a small target, and then there's all that padding. I'm wondering if while there's input if there's any way that the input div could somehow be the padding--generating a larger clickable target--yet still aligning the text in the right place? :-/

I threw in the padding because it felt awkward to get too close to the bottom. I'm not sure exactly what all could be done with the space (while running it could show a "I'm running dot-dot-dot" kind of animated icon there?")

@BrianOtto
Copy link
Collaborator

Maybe a larger min-width and min-height on the input div will do the trick? I think the vertical-align will keep the text aligned at the top, even if you add extra space. I'll try it out in the next couple days, if you don't get to it first.

@BrianOtto BrianOtto mentioned this issue Apr 13, 2019
Merged
@gchiu
Copy link
Collaborator
gchiu commented 8000 Apr 17, 2019

not working in the test-repl on Chrome

@BrianOtto
Copy link
Collaborator
BrianOtto commented Apr 18, 2019 •
edited
Loading

@gchiu What is the test-repl you are referring to? Also, have you tried clearing your cache and restarting the browser? The REPL will not work right after these changes until you do that.

@BrianOtto
Copy link
Collaborator

@gchiu Nevermind, I hadn't gone through all my GH notifications yet. I see you are talking about #62.

I just went through the tests in Chrome and everything was working for me. Was there a specific thing or step that failed?

@hostilefork hostilefork mentioned this issue Feb 18, 2021
Merged
@hostilefork
Copy link
Owner Author
hostilefork commented Mar 31, 2022 •
edited
Loading

Due to some complexities and atrophy of this feature, I thought to look into what it might take to do event forwarding... to forward right clicks or context menu events or whatever.

But it seems that programmatic triggering of context menus is simply not a supported scenario in today's browsers. I'm looking into other approaches but just wanted to write down that such forwarding won't work, and what I'd tried:

// https://stackoverflow.com/a/20541207
//
replpad.addEventListener('click', (e) => {
    if (e.target == replpad && input) {
         let new_e = new e.constructor(e.type, e);
         input.dispatchEvent(new_e);
         e.preventDefault()
     }
})

replpad.addEventListener('contextmenu', (e) => {
     if (e.target == replpad && input) {
         let new_e = new e.constructor(e.type, e);
         input.dispatchEvent(new_e);
         e.preventDefault()
     }
})

When right click happens we do not get the click event, just the contextmenu event.

I tried changing the coordinates but it didn't matter. Other sources on the internet corroborate that programmatic triggering of context menus on el 8000 ements is not a supported scenario.

@hostilefork hostilefork reopened this Mar 31, 2022
Repository owner deleted a comment from gchiu Apr 1, 2022
@hostilefork
Copy link
Owner Author

Took the last few days to rip things apart to the point I understood them well enough to throw in some ideas. Now I understand what @BrianOtto was talking about. :-)

I decided that display: inline is the way to go instead of display: inline-block, justification is here:

replpad-js/replpad.css

Lines 191 to 224 in b732b56

/* The preferred choice for input spans is `display: inline`. If it were
* `display: block` then a long prompt or text to the left would make the
* input unable to use the space underneath that prompt:
*
* YOUR LONG PROMPT HERE>> the input you type when it's long will wrap
* like this with `display: block`
*
* A second choice is `display: inline-block`, which looks good at first
*
* YOUR LONG PROMPT HERE>> so far so good for `display: inline-block`
*
* But it will jump to the next line if it gets too long for one line:
*
* YOUR LONG PROMPT HERE>>
* so far so good for `display: inline-block` but wait, now it's not
*
* With `display: inline` we get the desired wrapping...
*
* ...HOWEVER...there have been many unfortunate quirks encountered. They
* seem mitigated at this point (or at least feature ideas that triggered
* the quirks have been scrapped). At various points we've seen:
*
* [x] Empty inline elements have no insertion caret
* https://stackoverflow.com/q/25897883/
*
* [x] Cursor "jumps" between typing words on Android inline elements
* https://stackoverflow.com/q/68187400/
*
* ...as well as other problems. At one point the empty element cursor
* issue was solved with JavaScript flipping `inline` and `inline-block`
* based on detecting emptiness, but possibly using click() as well as
* doing a focus() sorted it out.
*/
display: inline;

But as pointed out, you can't use minimum width on that. It collapses to zero pixels. But I applied two tricks:

  • On the left I gave it a positive padding and a negative margin of the same size, which makes it overlap its left neighbor (if any, e.g. a prompt) a bit. It won't appear to affect the layout, but it errs on the side of letting you click into the input instead of selecting characters out of the prompt (or more likely, the space after the prompt)

  • I threw in some padding on the bottom, but only when it's focused. This gives some extra area to click in. Once the editing is finished it goes away, so it won't disrupt the content that prints after.

  • I used some display::after magic to tack on a few invisible spaces, which don't get copied or selected...but still count for the clickable region. Also only when focused.

Guess it will just be something to try for a while and see if it works well enough. Better ideas will always be welcome...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hostilefork hostilefork 4137

@BrianOtto BrianOtto

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hostilefork @gchiu @BrianOtto
0