All users were logged out of Bugzilla on October 13th, 2018

When all children in block are selected, copy should include the block parent

VERIFIED FIXED

Status

()

P2
normal
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: akkzilla, Assigned: mozeditor)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][p:2][PDTP2][rtm NEED INFO])

(Reporter)

Description

19 years ago
Related to bug 45994:

The selection system generally selects only the lowest level inline items, no
enclosing block nodes.  The clipboard system may need to be smarter than that.

If all of the inline children of a block node are selected, then upon copy, we
should also select the block node.

For example, if you select an entire paragraph and paste it somewhere, the
expectation might (*) be that upon pasting it somewhere else, it get pasted with
a <p> tag around it.

(*) One problem with this is that if you have, say, a list item consisting of
one word, there will no way to copy just that word.  Perhaps this behavior
should be easily switchable, so we can turn it on and then see if it ends up
being more annoying than useful.
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta2, polish
Target Milestone: --- → M18
Akkana, I'm almost certain you meant to nominate this nsbeta3 rather than 
nsbeta2, so I changed the keyword. If you really meant to nominate nsbeta2, 
please change it back and accept my apologies.
Keywords: nsbeta2 → nsbeta3
(Assignee)

Comment 2

19 years ago
in particular, you may als owant to grab blocks higher up the chain if all the 
_block_ children are selected.  ie, all the li's in an ol...
(Reporter)

Comment 3

19 years ago
Yes, nsbeta3.  Thanks for fixing it!

Comment 4

19 years ago
setting to nsbeta3+
Whiteboard: nsbeta3+
(Assignee)

Comment 5

19 years ago
altering suimmary.  it makes no differnece if children are inline or block.  if 
we have all the children, we want the parent.  and if the parent is an only 
child, we want the grandparent, etc...
Summary: When all inline children are selected, copy should include the block parent → When all children in block are selected, copy should include the block parent
(Assignee)

Comment 6

19 years ago
Note that this is not quite as straightforward as it first appears.  The 
selection may not include "non-editable" children, yet still include all the 
editable children.  To the user, this is the same as if all children are included 
(they cant see a difference).  I already have some code somewhere in the editor 
for doing these kinds of checks.  We should appropriate it for use in copy.

Comment 7

19 years ago
setting priority in status whiteboard
Whiteboard: nsbeta3+ → [nsbeta3+][p:1]

Comment 8

19 years ago
moving to m19
Keywords: nsbeta3
Whiteboard: [nsbeta3+][p:1] → [nsbeta3-]
Target Milestone: M18 → M19
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3

Comment 10

18 years ago
moving out to future
Keywords: helpwanted
Target Milestone: M19 → Future
(Assignee)

Comment 11

18 years ago
*** Bug 49728 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

18 years ago
stealing this bug because i'm such an incredibly nice guy...
Assignee: akkana → jfrancis
Status: ASSIGNED → NEW
(Assignee)

Comment 13

18 years ago
evil spirits in this program, COME OUT!
Status: NEW → ASSIGNED
(Assignee)

Comment 14

18 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

18 years ago
this is a test
(Assignee)

Comment 16

18 years ago
another test

Comment 17

18 years ago
Wasn't this backed out? If it was, the bug should be reopened.

Comment 18

18 years ago
had to back out for 50653...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

18 years ago
Blocks: 47014

Comment 19

18 years ago
bringing back in due to dependency
Whiteboard: [nsbeta3-] → [nsbeta3+]
Target Milestone: Future → M18
(Assignee)

Comment 20

18 years ago
I hear vidur&jst are removing XIF from our universe.  I'm not going to work on
this until after that happens since it will rock my world.
(Assignee)

Comment 21

18 years ago
See bug 43008: Vidur & JST are tearing out XIF and genreally repiping this whole 
part of the plumbing.  It does not make sense for me to touch this again until 
after that time.  Marking dependant....
Depends on: 43008

Comment 22

18 years ago
moving to m19, setting to -
Keywords: polish
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → M19

Comment 23

18 years ago
fixing this will assist in exporting correct HTML
reviewed by Bijal and beppe, setting to nsbeta3+, p2
Keywords: helpwanted → correctness
Priority: P3 → P2
Whiteboard: [nsbeta3-] → [nsbeta3+][p:2]

Comment 24

18 years ago
PDT agrees P2 based on discussion with beppe and ekrock
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:2][PDTP2]
(Assignee)

Updated

18 years ago
Depends on: 50742

Comment 25

18 years ago
Not holding PR3 for this, so marking nsbeta3-. Nominating for rtm since I 
understand XIF removal is important to the editor folks.
Keywords: rtm
Whiteboard: [nsbeta3+][p:2][PDTP2] → [nsbeta3-][p:2][PDTP2]

Comment 26

18 years ago
Joe, please include the required information per the rtm checkin rules
Whiteboard: [nsbeta3-][p:2][PDTP2] → [nsbeta3-][p:2][PDTP2][rtm+ NEED INFO]

Comment 27

18 years ago
removing + per pdt sw rules
Whiteboard: [nsbeta3-][p:2][PDTP2][rtm+ NEED INFO] → [nsbeta3-][p:2][PDTP2][rtm NEED INFO]
(Assignee)

Comment 28

18 years ago
fixed by noxif landing on trunk.  that was sr=kin, r=cast of thousands.
(Assignee)

Comment 29

18 years ago
fixed by noxif landing
(Assignee)

Comment 30

18 years ago
really marking fixed this time
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 31

18 years ago
verified in 10/16 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.